MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/4648
JIRA: https://issues.redhat.com/browse/RHEL-33234
CVE: CVE-2024-26866
Omitted-fix: 6c6871cdaef9 ("spi: Merge spi_controller.{slave,target}_abort()")
This fix would be nice to have, but isn't necessary at the moment, as RHEL doesn't enable
CONFIG_SPI_SLAVE and therefore this fix would have no runtime effect.
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
Approved-by: Brian Masney <bmasney@redhat.com>
Approved-by: Eric Chanudet <echanude@redhat.com>
Approved-by: CKI KWF Bot <cki-ci-bot+kwf-gitlab-com@redhat.com>
Merged-by: Lucas Zampieri <lzampier@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-27515
Omitted-fix: 4ae08845db4c1f759b8382bc7527ab8249230e7f
mfd: tps6594: Use spi_get_chipselect() API to access spi->chip_select
commit 303feb3cc06ac0665d0ee9c1414941200e60e8a3
Author: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Date: Fri Jan 20 00:23:30 2023 +0530
spi: Add APIs in spi core to set/get spi->chip_select and spi->cs_gpiod
Supporting multi-cs in spi core and spi controller drivers would require
the chip_select & cs_gpiod members of struct spi_device to be an array.
But changing the type of these members to array would break the spi driver
functionality. To make the transition smoother introduced four new APIs to
get/set the spi->chip_select & spi->cs_gpiod and replaced all
spi->chip_select and spi->cs_gpiod references in spi core with the API
calls.
While adding multi-cs support in further patches the chip_select & cs_gpiod
members of the spi_device structure would be converted to arrays & the
"idx" parameter of the APIs would be used as array index i.e.,
spi->chip_select[idx] & spi->cs_gpiod[idx] respectively.
Suggested-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Reviewed-by: Michal Simek <michal.simek@amd.com>
Link: https://lore.kernel.org/r/20230119185342.2093323-2-amit.kumar-mahapatra@amd.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jaroslav Kysela <jkysela@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-27515
Omitted-fix: f6c911f3308c1cfb97ae1da6654080d7104e2df2
spi: dt-bindings: Introduce spi-cs-setup-ns property
not used in RHEL
Omitted-fix: 33a2fde5f77bd744b8bd0c694bc173cc968e55a5
spi: Introduce spi-cs-setup-ns property
not used in RHEL
Omitted-fix: f732646d0ccd22f42ed7de5e59c0abb7a848e034
spi: atmel-quadspi: Add support for configuring CS timing
not used in RHEL
commit 684a47847ae639689e7b823251975348a8e5434f
Author: Tudor Ambarus <tudor.ambarus@microchip.com>
Date: Thu Nov 17 12:52:44 2022 +0200
spi: Reintroduce spi_set_cs_timing()
commit 4ccf359849 ("spi: remove spi_set_cs_timing()"), removed the
method as noboby used it. Nobody used it probably because some SPI
controllers use some default large cs-setup time that covers the usual
cs-setup time required by the spi devices. There are though SPI controllers
that have a smaller granularity for the cs-setup time and their default
value can't fulfill the spi device requirements. That's the case for the
at91 QSPI IPs where the default cs-setup time is half of the QSPI clock
period. This was observed when using an sst26vf064b SPI NOR flash which
needs a spi-cs-setup-ns = <7>; in order to be operated close to its maximum
104 MHz frequency.
Call spi_set_cs_timing() in spi_setup() just before calling spi_set_cs(),
as the latter needs the CS timings already set.
If spi->controller->set_cs_timing is not set, the method will return 0.
There's no functional impact expected for the existing drivers. Even if the
spi-mt65xx.c and spi-tegra114.c drivers set the set_cs_timing method,
there's no user for them as of now. The only tested user of this support
will be a SPI NOR flash that comunicates with the Atmel QSPI controller for
which the support follows in the next patches.
One will notice that this support is a bit different from the one that was
removed in commit 4ccf359849 ("spi: remove spi_set_cs_timing()"),
because this patch adapts to the changes done after the removal: the move
of the cs delays to the spi device, the retirement of the lelgacy GPIO
handling. The mutex handling was removed from spi_set_cs_timing() because
we now always call spi_set_cs_timing() in spi_setup(), which already
handles the spi->controller->io_mutex, so use the mutex handling from
spi_setup().
Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
Link: https://lore.kernel.org/r/20221117105249.115649-4-tudor.ambarus@microchip.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Jaroslav Kysela <jkysela@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-33234
commit b8d3b056a78dcc941fd1a117697ab2b956c2953f
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Tue Oct 11 17:22:04 2022 +0800
spi: introduce new helpers with using modern naming
For using modern names host/target to instead of all the legacy names,
I think it takes 3 steps:
- step1: introduce new helpers with modern naming.
- step2: switch to use these new helpers in all drivers.
- step3: remove all legacy helpers and update all legacy names.
This patch is for step1, it introduces new helpers with host/target
naming for drivers using.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221011092204.950288-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-38218
CVE: CVE-2023-52749
Conflicts: Due to missing commit
82238d2cbd99e ("spi: Rename SPI_MASTER_GPIO_SS to SPI_CONTROLLER_GPIO_SS")
some context diffs were introduced. That commit touches too
much of SPI, let's take that as part of a subsystem upgrade
but not for this one patch.
commit bef4a48f4ef798c4feddf045d49e53c8a97d5e37
Author: Mark Hasemeyer <markhas@chromium.org>
Date: Tue Nov 7 14:47:43 2023 -0700
spi: Fix null dereference on suspend
A race condition exists where a synchronous (noqueue) transfer can be
active during a system suspend. This can cause a null pointer
dereference exception to occur when the system resumes.
Example order of events leading to the exception:
1. spi_sync() calls __spi_transfer_message_noqueue() which sets
ctlr->cur_msg
2. Spi transfer begins via spi_transfer_one_message()
3. System is suspended interrupting the transfer context
4. System is resumed
6. spi_controller_resume() calls spi_start_queue() which resets cur_msg
to NULL
7. Spi transfer context resumes and spi_finalize_current_message() is
called which dereferences cur_msg (which is now NULL)
Wait for synchronous transfers to complete before suspending by
acquiring the bus mutex and setting/checking a suspend flag.
Signed-off-by: Mark Hasemeyer <markhas@chromium.org>
Link: https://lore.kernel.org/r/20231107144743.v1.1.I7987f05f61901f567f7661763646cb7d7919b528@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@kernel.org
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-39777
CVE: CVE-2024-36930
commit 4756fa529b2f12b7cb8f21fe229b0f6f47190829
Author: Mans Rullgard <mans@mansr.com>
Date: Tue Apr 30 19:27:05 2024 +0100
spi: fix null pointer dereference within spi_sync
If spi_sync() is called with the non-empty queue and the same spi_message
is then reused, the complete callback for the message remains set while
the context is cleared, leading to a null pointer dereference when the
callback is invoked from spi_finalize_current_message().
With function inlining disabled, the call stack might look like this:
_raw_spin_lock_irqsave from complete_with_flags+0x18/0x58
complete_with_flags from spi_complete+0x8/0xc
spi_complete from spi_finalize_current_message+0xec/0x184
spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474
spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230
__spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4
__spi_transfer_message_noqueue from __spi_sync+0x204/0x248
__spi_sync from spi_sync+0x24/0x3c
spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]
mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154
_regmap_raw_read from _regmap_bus_read+0x44/0x70
_regmap_bus_read from _regmap_read+0x60/0xd8
_regmap_read from regmap_read+0x3c/0x5c
regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]
mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]
mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78
irq_thread_fn from irq_thread+0x118/0x1f4
irq_thread from kthread+0xd8/0xf4
kthread from ret_from_fork+0x14/0x28
Fix this by also setting message->complete to NULL when the transfer is
complete.
Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync")
Signed-off-by: Mans Rullgard <mans@mansr.com>
Link: https://lore.kernel.org/r/20240430182705.13019-1-mans@mansr.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Andrew Halaney <ahalaney@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-22420
commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Thu, 30 Mar 2023 15:26:13 +0200
When loading a DT overlay that creates a device, the device is not
probed, unless the DT overlay is unloaded and reloaded again.
After the recent refactoring to improve fw_devlink, it no longer depends
on the "compatible" property to identify which device tree nodes will
become struct devices. fw_devlink now picks up dangling consumers
(consumers pointing to descendent device tree nodes of a device that
aren't converted to child devices) when a device is successfully bound
to a driver. See __fw_devlink_pickup_dangling_consumers().
However, during DT overlay, a device's device tree node can have
sub-nodes added/removed without unbinding/rebinding the driver. This
difference in behavior between the normal device instantiation and
probing flow vs. the DT overlay flow has a bunch of implications that
are pointed out elsewhere[1]. One of them is that the fw_devlink logic
to pick up dangling consumers is never exercised.
This patch solves the fw_devlink issue by marking all DT nodes added by
DT overlays with FWNODE_FLAG_NOT_DEVICE (fwnode that won't become
device), and by clearing the flag when a struct device is actually
created for the DT node. This way, fw_devlink knows not to have
consumers waiting on these newly added DT nodes, and to propagate the
dependency to an ancestor DT node that has the corresponding struct
device.
Based on a patch by Saravana Kannan, which covered only platform and spi
devices.
[1] https://lore.kernel.org/r/CAGETcx_bkuFaLCiPrAWCPQz+w79ccDp6=9e881qmK=vx3hBMyg@mail.gmail.com
Fixes: 4a032827daa89350 ("of: property: Simplify of_link_to_phandle()")
Link: https://lore.kernel.org/r/CAGETcx_+rhHvaC_HJXGrr5_WAd2+k5f=rWYnkCZ6z5bGX-wj4w@mail.gmail.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Wolfram Sang <wsa@kernel.org> # for I2C
Acked-by: Shawn Guo <shawnguo@kernel.org>
Acked-by: Saravana Kannan <saravanak@google.com>
Tested-by: Ivan Bornyakov <i.bornyakov@metrotek.ru>
Link: https://lore.kernel.org/r/e1fa546682ea4c8474ff997ab6244c5e11b6f8bc.1680182615.git.geert+renesas@glider.be
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Rupinderjit Singh <rusingh@redhat.com>
MR: https://gitlab.com/redhat/centos-stream/src/kernel/centos-stream-9/-/merge_requests/2940
JIRA: https://issues.redhat.com/browse/RHEL-1023
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
Approved-by: Phil Auld <pauld@redhat.com>
Approved-by: Tony Camuso <tcamuso@redhat.com>
Approved-by: Antoine Tenart <atenart@redhat.com>
Approved-by: Jocelyn Falempe <jfalempe@redhat.com>
Approved-by: Chris von Recklinghausen <crecklin@redhat.com>
Approved-by: Prarit Bhargava <prarit@redhat.com>
Approved-by: John W. Linville <linville@redhat.com>
Approved-by: Vladis Dronov <vdronov@redhat.com>
Approved-by: Donald Dutile <ddutile@redhat.com>
Approved-by: Eric Chanudet <echanude@redhat.com>
Signed-off-by: Jan Stancek <jstancek@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-1023
Conflicts:
drivers/ptp/ptp_ocp.c - struct timecard_class
doesn't exist, so it wasn't possible to remove its
.owner field
commit 10a03c36b7dd7759788ebc613091d313b60f93e0
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 17 Mar 2023 15:16:27 +0000
There is no need to manually set the owner of a struct class, as the
registering function does it automatically, so remove all of the
explicit settings from various drivers that did so as it is unneeded.
This allows us to remove this pointer entirely from this structure going
forward.
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Link: https://lore.kernel.org/r/20230313181843.1207845-2-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-1349
Upstream Status: v6.4-rc1
commit 673aa1ed1c9b6710bf24e3f0957d85e2f46c77db
Author: Miquel Raynal <miquel.raynal@bootlin.com>
AuthorDate: Tue Apr 4 18:21:16 2023 +0100
Commit: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Wed Apr 5 19:41:10 2023 +0200
This helper does not produce a real modalias, but tries to get the
"product" compatible part of the "vendor,product" compatibles only. It
is far from creating a purely useful modalias string and does not seem
to be used like that directly anyway, so let's try to give this helper a
more meaningful name before moving there a real modalias helper (already
existing under of/device.c).
Also update the various documentations to refer to the strings as
"aliases" rather than "modaliases" which has a real meaning in the Linux
kernel.
There is no functional change.
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Sebastian Reichel <sre@kernel.org>
Cc: Wolfram Sang <wsa@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Acked-by: Sebastian Reichel <sre@kernel.org>
Link: https://lore.kernel.org/r/20230404172148.82422-9-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
JIRA: https://issues.redhat.com/browse/RHEL-1023
Conflicts:
drivers/gpu/drm/drm_mipi_dsi.c - minor context
differences
drivers/platform/x86/wmi.c - had to insert a const
in device_to_wblock()
include/linux/hyperv.h - had to insert a const
in device_to_hv_device()
Omitted-fix: a69ea7a76d52353b17d7bedf43818c2578517e9e
centos-9 doesn't support SuperH devices, so this
fix for the maple sub-componet of a SuperH isn't
necessary
commit 2a81ada32f0e584fc0c943e0d3a8c9f4fae411d6
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Fri, 27 Jan 2023 13:45:52 +0000
The uevent() callback in struct bus_type should not be modifying the
device that is passed into it, so mark it as a const * and propagate the
function signature changes out into all relevant subsystems that use
this callback.
Acked-by: Rafael J. Wysocki <rafael@kernel.org>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20230111113018.459199-16-gregkh@linuxfoundation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2193170
commit 93cc2559d3fdcd28b1a7972ab519a6cd8ba20f9d
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Wed Oct 26 14:29:51 2022 +0200
spi: Remove the obsolte u64_stats_fetch_*_irq() users.
Now that the 32bit UP oddity is gone and 32bit uses always a sequence
count, there is no need for the fetch_irq() variants anymore.
Convert to the regular interface.
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20221026122951.331638-1-bigeasy@linutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2176554
commit 62fcb99bdf10fed34b4fe6e225489fe4be2d0536
Author: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Date: Wed, 24 Aug 2022 18:59:48 +0200
The parent field in struct acpi_device is, in fact, redundant,
because the dev.parent field in it effectively points to the same
object and it is used by the driver core.
Accordingly, the parent field can be dropped from struct acpi_device
and for this purpose define acpi_dev_parent() to retrieve a parent
struct acpi_device pointer from the dev.parent field in struct
acpi_device. Next, update all of the users of the parent field
in struct acpi_device to use acpi_dev_parent() instead of it and
drop it.
While at it, drop the ACPI_IS_ROOT_DEVICE() macro that is only used
in one place in a confusing way.
No intentional functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Wei Liu <wei.liu@kernel.org>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 8e9204cddcc3fea9affcfa411715ba4f66e97587
Author: Marek Szyprowski <m.szyprowski@samsung.com>
Date: Fri, 30 Sep 2022 13:34:08 +0200
SPI code checks for non-zero sgt->orig_nents to determine if the buffer
has been DMA-mapped. Ensure that sg_table is really zeroed after free to
avoid potential NULL pointer dereference if the given SPI xfer object is
reused again without being DMA-mapped.
Fixes: 0c17ba73c08f ("spi: Fix cache corruption due to DMA/PIO overlap")
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20220930113408.19720-1-m.szyprowski@samsung.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 8d699ff95534747e394e0830399b8d5dcf03e738
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date: Tue, 27 Sep 2022 13:21:16 +0200
A couple of drivers call spi_split_transfers_maxsize() from their
->prepare_message() callbacks to split transfers which are too big for
them to handle. Add support in the core to do this based on
->max_transfer_size() to avoid code duplication.
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220927112117.77599-4-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 0c17ba73c08ff2690c1eff8df374b6709eed55ce
Author: Vincent Whitchurch <vincent.whitchurch@axis.com>
Date: Tue, 27 Sep 2022 13:21:15 +0200
The SPI core DMA mapping support performs cache management once for the
entire message and not between transfers, and this leads to cache
corruption if a message has two or more RX transfers with both
transfers targeting the same cache line, and the controller driver
decides to handle one using DMA and the other using PIO (for example,
because one is much larger than the other).
Fix it by syncing before/after the actual transfers. This also means
that we can skip the sync during the map/unmap of the message.
Fixes: 99adef310f ("spi: Provide core support for DMA mapping transfers")
Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/r/20220927112117.77599-3-vincent.whitchurch@axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 5e0531f6b90ac096fedaf5bd0eae0bb4e5a39da5
Author: Christophe Leroy <christophe.leroy@csgroup.eu>
Date: Wed, 7 Sep 2022 16:11:25 +0200
Some components require a few clock cycles with chipselect off before
or/and after the data transfer done with CS on.
Typically IDT 801034 QUAD PCM CODEC datasheet states "Note *: CCLK
should have one cycle before CS goes low, and two cycles after
CS goes high".
The cycles "before" are implicitely provided by all previous activity
on the SPI bus. But the cycles "after" must be provided in order to
terminate the SPI transfer.
In order to use that kind of component, add a cs_off flag to
spi_transfer struct. When this flag is set, the transfer is performed
with chipselect off. This allows consummer to add a dummy transfer
at the end of the transfer list which is performed with chipselect
OFF, providing the required additional clock cycles.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Link: https://lore.kernel.org/r/434165c46f06d802690208a11e7ea2500e8da4c7.1662558898.git.christophe.leroy@csgroup.eu
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 9c9c9da7aa108e6bf952c18289527a5234e4fc59
Author: David Jander <david@protonic.nl>
Date: Thu, 1 Sep 2022 14:36:30 +0200
The queue worker always needs to be kicked one final time after a transfer
is done in order to transition to idle (ctlr->busy = false).
Commit 69fa95905d40 ("spi: Ensure the io_mutex is held until
spi_finalize_current_message()") moved this code into
__spi_pump_messages(), but it was executed only if the transfer was
successful. This condition check causes ctlr-busy to stay true in case of
a failed transfer.
This in turn causes that no new work is ever scheduled to the work queue.
Fixes: 69fa95905d40 ("spi: Ensure the io_mutex is held until spi_finalize_current_message()")
Reported-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220901123630.1098433-1-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit b30f7c8eb0780e1479a9882526e838664271f4c9
Author: Mark Brown <broonie@kernel.org>
Date: Thu, 1 Sep 2022 13:07:32 +0100
The spi-mux driver is rather too clever and attempts to resubmit any
message that is submitted to it to the parent controller with some
adjusted callbacks. This does not play at all nicely with the fast
path which now sets flags on the message indicating that it's being
handled through the fast path, we see async messages flagged as being on
the fast path. Ideally the spi-mux code would duplicate the message but
that's rather invasive and a bit fragile in that it relies on the mux
knowing which fields in the message to copy. Instead teach the core
that there are controllers which can't cope with the fast path and have
the mux flag itself as being such a controller, ensuring that messages
going via the mux don't get partially handled via the fast path.
This will reduce the performance of any spi-mux connected device since
we'll now always use the thread for both the actual controller and the
mux controller instead of just the actual controller but given that we
were always hitting the slow path anyway it's hopefully not too much of
an additional cost and it allows us to keep the fast path.
Fixes: ae7d2346dc89 ("spi: Don't use the message queue if possible in spi_sync")
Reported-by: Casper Andersson <casper.casan@gmail.com>
Tested-by: Casper Andersson <casper.casan@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220901120732.49245-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 43cc5a0afe4184a7fafe1eba32b5a11bb69c9ce0
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Tue, 12 Jul 2022 21:55:04 +0800
This reverts commit 59ebbe40fb ("spi: simplify
devm_spi_register_controller").
If devm_add_action() fails in devm_add_action_or_reset(),
devm_spi_unregister() will be called, it decreases the
refcount of 'ctlr->dev' to 0, then it will cause uaf in
the drivers that calling spi_put_controller() in error path.
Fixes: 59ebbe40fb ("spi: simplify devm_spi_register_controller")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20220712135504.1055688-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
Conflicts:
include/linux/spi/spi.h
No backport of commit 04e6bb0d6bb1 "spi: modify set_cs_timing
parameter"
commit 95c8222f0e52b09b7607616274e7cae84d519a9b
Author: David Jander <david@protonic.nl>
Date: Wed, 29 Jun 2022 16:25:18 +0200
Capitalize first word in comment where appropriate and add
parentheses to function names.
Reported-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220629142519.3985486-3-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit dc3029056b02414c29b6627e3dd7b16624725ae9
Author: David Jander <david@protonic.nl>
Date: Tue, 21 Jun 2022 08:12:34 +0200
There are only a few drivers that do not call
spi_finalize_current_message() in the context of transfer_one_message(),
and even for those cases the completion ctlr->cur_msg_completion is not
needed always. The calls to complete() and wait_for_completion() each
take a spin-lock, which is costly. This patch makes it possible to avoid
those calls in the big majority of cases, by introducing two flags that
with the help of ordering via barriers can avoid using the completion
safely. In case of a race with the context calling
spi_finalize_current_message(), the scheme errs on the safe side and takes
the completion.
The impact of this patch is worth the effort: On a i.MX8MM SoC, the time
the SPI bus is idle between two consecutive calls to spi_sync(), is
reduced from 19.6us to 16.8us... roughly 15%.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-12-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 69fa95905d40846756d22402690ddf5361a9d13b
Author: David Jander <david@protonic.nl>
Date: Tue, 21 Jun 2022 08:12:33 +0200
This patch introduces a completion that is completed in
spi_finalize_current_message() and waited for in
__spi_pump_transfer_message(). This way all manipulation of ctlr->cur_msg
is done with the io_mutex held and strictly ordered:
__spi_pump_transfer_message() will not return until
spi_finalize_current_message() is done using ctlr->cur_msg, and its
calling context is only touching ctlr->cur_msg after returning.
Due to this, we can safely drop the spin-locks around ctlr->cur_msg.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-11-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit ae7d2346dc89ae89a6e0aabe6037591a11e593c0
Author: David Jander <david@protonic.nl>
Date: Tue, 21 Jun 2022 08:12:25 +0200
The interaction with the controller message queue and its corresponding
auxiliary flags and variables requires the use of the queue_lock which is
costly. Since spi_sync will transfer the complete message anyway, and not
return until it is finished, there is no need to put the message into the
queue if the queue is empty. This can save a lot of overhead.
As an example of how significant this is, when using the MCP2518FD SPI CAN
controller on a i.MX8MM SoC, the time during which the interrupt line
stays active (during 3 relatively short spi_sync messages), is reduced
from 98us to 72us by this patch.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-3-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 1714582a3a087eda8786d5a1b32b2ec86ca8a303
Author: David Jander <david@protonic.nl>
Date: Tue, 21 Jun 2022 08:12:24 +0200
This enables the possibility to transfer a message that is not at the
current tip of the async message queue.
This is in preparation of the next patch(es) which enable spi_sync messages
to skip the queue altogether.
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220621061234.3626638-2-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 6598b91b5ac32bc756d7c3000a31f775d4ead1c4
Author: David Jander <david@protonic.nl>
Date: Tue, 24 May 2022 11:18:08 +0200
This change gives a dramatic performance improvement in the hot path,
since many costly spin_lock_irqsave() calls can be avoided.
On an i.MX8MM system with a MCP2518FD CAN controller connected via SPI,
the time the driver takes to handle interrupts, or in other words the time
the IRQ line of the CAN controller stays low is mainly dominated by the
time it takes to do 3 relatively short sync SPI transfers. The effect of
this patch is a reduction of this time from 136us down to only 98us.
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: David Jander <david@protonic.nl>
Link: https://lore.kernel.org/r/20220524091808.2269898-1-david@protonic.nl
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit 73f93db5c49b9f52c902e5dc6c750bf9832e0450
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Thu, 14 Apr 2022 10:40:40 +0200
The previous commit that made bits-per-word validation conditional
results in leaving no unconditional affectation of the status variable.
Since the variable is returned at the end of the function, initialize
it to avoid returning an undefined value.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Fixes: b3fe2e516741 ("spi: core: Only check bits_per_word validity when explicitly provided")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20220414084040.975520-1-paul.kocialkowski@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2071848
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2122415
commit b3fe2e516741368a643d79527ebccfe557217a53
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Date: Tue, 12 Apr 2022 14:22:07 +0200
On SPI device probe, the core will call spi_setup in spi_add_device
before the corresponding driver was probed. When this happens, the
bits_per_word member of the device is not yet set by the driver,
resulting in the default being set to 8 bits-per-word.
However some controllers do not support 8 bits-per-word at all, which
results in a failure when checking the bits-per-word validity.
In order to support these devices, skip the bits-per-word validity
check when it is not explicitly provided by drivers.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Link: https://lore.kernel.org/r/20220412122207.130181-1-paul.kocialkowski@bootlin.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mark Salter <msalter@redhat.com>
Lucas Zampieri
Jaroslav Kysela
Andrew Halaney
Rupinderjit Singh
Jan Stancek
Mark Langsdorf
Mika Penttilä
Ivan Vecera
Mark Salter