summaryrefslogtreecommitdiff
path: root/drivers/spi
AgeCommit message (Collapse)AuthorFilesLines
2020-12-11Merge remote-tracking branch 'spi/for-5.11' into spi-nextMark Brown39-220/+423
2020-12-11spi: Limit the spi device max speed to controller's max speedTudor Ambarus1-1/+2
Make sure the max_speed_hz of spi_device does not override the max_speed_hz of controller. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201209173514.93328-1-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-10Merge series "spi: spi-geni-qcom: Use gpio descriptors for CS" from Stephen ↵Mark Brown1-0/+1
Boyd <swboyd@chromium.org>: Collected patches from the two series below and associated tags so they can be merged in one pile through the spi tree. Merry December! SPI: https://lore.kernel.org/r/20201202214935.1114381-1-swboyd@chromium.org cros-ec: https://lore.kernel.org/r/20201203011649.1405292-1-swboyd@chromium.org Cc: Akash Asthana <akashast@codeaurora.org> Cc: Simon Glass <sjg@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Cc: Douglas Anderson <dianders@chromium.org> Cc: Alexandru M Stan <amstan@chromium.org> Stephen Boyd (3): platform/chrome: cros_ec_spi: Don't overwrite spi::mode platform/chrome: cros_ec_spi: Drop bits_per_word assignment spi: spi-geni-qcom: Use the new method of gpio CS control drivers/platform/chrome/cros_ec_spi.c | 2 -- drivers/spi/spi-geni-qcom.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) base-commit: b65054597872ce3aefbc6a666385eabdf9e288da -- https://chromeos.dev
2020-12-09spi: spi-geni-qcom: Use the new method of gpio CS controlStephen Boyd1-0/+1
Let's set the 'use_gpio_descriptors' field so that we use the new way of requesting the CS GPIOs in the core. This allows us to avoid having to configure the CS pins in "output" mode with an 'output-enable' pinctrl setting. Cc: Akash Asthana <akashast@codeaurora.org> Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20201204193540.3047030-4-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09spi: dw: Add support for the Canaan K210 SoC SPIDamien Le Moal1-0/+16
The Canaan Kendryte K210 RISC-V SoC includes a DW apb_ssi v4 controller which is documented to have a 32 words deep TX and RX FIFO. The FIFO length detection in spi_hw_init() correctly detects this value. However, when the controller RX FIFO is filled up to 32 entries (RXFLR = 32), an RX FIFO overrun error occurs. This likely due to a hardware bug which can be avoided by force setting the fifo_len field of struct dw_spi to 31. Define the dw_spi_canaan_k210_init() function to force set fifo_len to 31 when the device node compatible string is "canaan,k210-spi". Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-4-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-09spi: dw: Add support for 32-bits max xfer sizeDamien Le Moal2-7/+42
The Synopsis DesignWare DW_apb_ssi specifications version 3.23 onward define a 32-bits maximum transfer size synthesis parameter (SSI_MAX_XFER_SIZE=32) in addition to the legacy 16-bits configuration (SSI_MAX_XFER_SIZE=16) for SPI controllers. When SSI_MAX_XFER_SIZE=32, the layout of the ctrlr0 register changes, moving the data frame format field from bits [3..0] to bits [16..20], and the RX/TX FIFO word size can be up to 32-bits. To support this new format, introduce the DW SPI capability flag DW_SPI_CAP_DFS32 to indicate that a controller is configured with SSI_MAX_XFER_SIZE=32. Since SSI_MAX_XFER_SIZE is a controller synthesis parameter not accessible through a register, the detection of this parameter value is done in spi_hw_init() by writing and reading the ctrlr0 register and testing the value of bits [3..0]. These bits are ignored (unchanged) for SSI_MAX_XFER_SIZE=16, allowing the detection. If a DFS32 capable SPI controller is detected, the new field dfs_offset in struct dw_spi is set to SPI_DFS32_OFFSET (16). dw_spi_update_config() is modified to set the data frame size field at the correct position is the CTRLR0 register, as indicated by the dfs_offset field of the dw_spi structure. The DW_SPI_CAP_DFS32 flag is also unconditionally set for SPI slave controllers, e.g. controllers that have the DW_SPI_CAP_DWC_SSI capability flag set. However, for these ssi controllers, the dfs_offset field is set to 0 as before (as per specifications). Finally, for any controller with the DW_SPI_CAP_DFS32 capability flag set, dw_spi_add_host() extends the value of bits_per_word_mask from 16-bits to 32-bits. dw_reader() and dw_writer() are also modified to handle 32-bits iTX/RX FIFO words. Suggested-by: Sean Anderson <seanga2@gmail.com> Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201206011817.11700-3-damien.lemoal@wdc.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07Merge series "spi: atmel-quadspi: Fix AHB memory accesses" from Tudor ↵Mark Brown1-12/+13
Ambarus <tudor.ambarus@microchip.com>: Starting with the move of the atmel-quadspi driver under SPI, the following error could be seen when mounting a 16MByte ubifs: UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type 1/4 fixes AHB accesses. The rest of the patches are small optimizations. Tested on both sama5d2 and sam9x60. Tudor Ambarus (4): spi: atmel-quadspi: Fix AHB memory accesses spi: atmel-quadspi: Drop superfluous set of QSPI_IFR_APBTFRTYP_READ spi: atmel-quadspi: Write QSPI_IAR only when needed spi: atmel-quadspi: Move common code outside of if else drivers/spi/atmel-quadspi.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) -- 2.25.1 base-commit: 3650b228f83adda7e5ee532e2b90429c03f7b9ec _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-12-07spi: atmel-quadspi: Fix use-after-free on unbindLukas Wunner1-10/+5
atmel_qspi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.0+ Cc: Piotr Bugalski <bugalski.piotr@gmail.com> Link: https://lore.kernel.org/r/4b05c65cf6f1ea3251484fe9a00b4c65478a1ae3.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: npcm-fiu: Disable clock in probe error pathLukas Wunner1-2/+6
If the call to devm_spi_register_master() fails on probe of the NPCM FIU SPI driver, the clock "fiu->clk" is erroneously not unprepared and disabled. Fix it. Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.4+ Cc: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/9ae62f4e1cfe542bec57ac2743e6fca9f9548f55.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: ar934x: Don't leak SPI master in probe error pathLukas Wunner1-3/+11
If the call to devm_spi_register_controller() fails on probe of the Qualcomm Atheros AR934x/QCA95xx SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Moreover, the controller's clock is enabled on probe but not disabled if any of the subsequent probe steps fail. Finally, there's an ordering issue in ar934x_spi_remove() wherein the clock is disabled even though the controller is not yet unregistered. It is unregistered after ar934x_spi_remove() by the devres framework. As long as it is not unregistered, SPI transfers may still be ongoing and disabling the clock may break them. It is not possible to use devm_spi_register_controller() in this case, so move to the non-devm variant. All of these bugs have existed since the driver was first introduced, so it seems fair to fix them together in a single commit. Fixes: 047980c582af ("spi: add driver for ar934x spi controller") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.7+ Cc: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/1d58367d74d55741e0c2730a51a2b65012c8ab33.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: mt7621: Don't leak SPI master in probe error pathLukas Wunner1-2/+3
If the calls to device_reset() or devm_spi_register_controller() fail on probe of the MediaTek MT7621 SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Additionally, there's an ordering issue in mt7621_spi_remove() wherein the spi_controller is unregistered after disabling the SYS clock. The correct order is to call spi_unregister_controller() *before* this teardown step because bus accesses may still be ongoing until that function returns. All of these bugs have existed since the driver was first introduced, so it seems fair to fix them together in a single commit. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Stefan Roese <sr@denx.de> Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.17+ Link: https://lore.kernel.org/r/72b680796149f5fcda0b3f530ffb7ee73b04f224.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: mt7621: Disable clock in probe error pathLukas Wunner1-1/+5
Commit 702b15cb9712 ("spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe") sought to disable the SYS clock on probe errors, but only did so for 2 of 3 potentially failing calls: The clock needs to be disabled on failure of devm_spi_register_controller() as well. Moreover, the commit purports to fix a bug in commit cbd66c626e16 ("spi: mt7621: Move SPI driver out of staging") but in reality the bug has existed since the driver was first introduced. Fixes: 1ab7f2a43558 ("staging: mt7621-spi: add mt7621 support") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.17+: 702b15cb9712: spi: mt7621: fix missing clk_disable_unprepare() on error in mt7621_spi_probe Cc: <stable@vger.kernel.org> # v4.17+ Cc: Qinglang Miao <miaoqinglang@huawei.com> Link: https://lore.kernel.org/r/36ad42760087952fb7c10aae7d2628547c26a7ec.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: sc18is602: Don't leak SPI master in probe error pathLukas Wunner1-11/+2
If the call to devm_gpiod_get_optional() fails on probe of the NXP SC18IS602/603 SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: f99008013e19 ("spi: sc18is602: Add reset control via gpio pin.") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.9+ Cc: Phil Reid <preid@electromag.com.au> Link: https://lore.kernel.org/r/d5f715527b894b91d530fe11a86f51b3184a4e1a.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: rb4xx: Don't leak SPI master in probe error pathLukas Wunner1-1/+1
If the calls to devm_clk_get(), devm_spi_register_master() or clk_prepare_enable() fail on probe of the Mikrotik RB4xx SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: 05aec357871f ("spi: Add SPI driver for Mikrotik RB4xx series boards") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.2+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.2+ Cc: Bert Vermeulen <bert@biot.com> Link: https://lore.kernel.org/r/369bf26d71927f60943b1d9d8f51810f00b0237d.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: gpio: Don't leak SPI master in probe error pathLukas Wunner1-13/+2
If the call to devm_spi_register_master() fails on probe of the GPIO SPI driver, the spi_master struct is erroneously not freed: After allocating the spi_master, its reference count is 1. The driver unconditionally decrements the reference count on unbind using a devm action. Before calling devm_spi_register_master(), the driver unconditionally increments the reference count because on success, that function will decrement the reference count on unbind. However on failure, devm_spi_register_master() does *not* decrement the reference count, so the spi_master is leaked. The issue was introduced by commits 8b797490b4db ("spi: gpio: Make sure spi_master_put() is called in every error path") and 79567c1a321e ("spi: gpio: Use devm_spi_register_master()"), which sought to plug leaks introduced by 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors") but missed this remaining leak. The situation was later aggravated by commit d3b0ffa1d75d ("spi: gpio: prevent memory leak in spi_gpio_probe"), which introduced a use-after-free because it releases a reference on the spi_master if devm_add_action_or_reset() fails even though the function already does that. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: 9b00bc7b901f ("spi: spi-gpio: Rewrite to use GPIO descriptors") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: <stable@vger.kernel.org> # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.1-: 8b797490b4db: spi: gpio: Make sure spi_master_put() is called in every error path Cc: <stable@vger.kernel.org> # v5.1-: 45beec351998: spi: bitbang: Introduce spi_bitbang_init() Cc: <stable@vger.kernel.org> # v5.1-: 79567c1a321e: spi: gpio: Use devm_spi_register_master() Cc: <stable@vger.kernel.org> # v5.4-: d3b0ffa1d75d: spi: gpio: prevent memory leak in spi_gpio_probe Cc: <stable@vger.kernel.org> # v4.17+ Cc: Navid Emamdoost <navid.emamdoost@gmail.com> Cc: Andrey Smirnov <andrew.smirnov@gmail.com> Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: spi-mtk-nor: Don't leak SPI master in probe error pathLukas Wunner1-1/+1
If the call to devm_spi_register_controller() fails on probe of the MediaTek SPI NOR driver, the spi_controller struct is erroneously not freed. Since commit a1daaa991ed1 ("spi: spi-mtk-nor: use dma_alloc_coherent() for bounce buffer"), the same happens if the call to dmam_alloc_coherent() fails. Since commit 3bfd9103c7af ("spi: spi-mtk-nor: Add power management support"), the same happens if the call to mtk_nor_enable_clk() fails. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: 881d1ee9fe81 ("spi: add support for mediatek spi-nor controller") Signed-off-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ikjoon Jang <ikjn@chromium.org> Cc: <stable@vger.kernel.org> # v5.7+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.7+ Cc: Chuanhong Guo <gch981213@gmail.com> Link: https://lore.kernel.org/r/d5b9f0289465394e73dedb8ec51e180a8f1dffc9.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: mxic: Don't leak SPI master in probe error pathLukas Wunner1-8/+2
If the calls to devm_clk_get() or devm_ioremap_resource() fail on probe of the Macronix SPI driver, the spi_master struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: b942d80b0a39 ("spi: Add MXIC controller driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.0+ Cc: Mason Yang <masonccyang@mxic.com.tw> Link: https://lore.kernel.org/r/4fa6857806e7e75741c05d057ac9df3564460114.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: rpc-if: Fix use-after-free on unbindLukas Wunner1-7/+2
rpcif_spi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: eb8d6d464a27 ("spi: add Renesas RPC-IF driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.9+ Cc: Sergei Shtylyov <s.shtylyov@omprussia.ru> Link: https://lore.kernel.org/r/c5da472c28021da2f6517441685cef033d40b140.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: pxa2xx: Fix use-after-free on unbindLukas Wunner1-3/+2
pxa2xx_spi_remove() accesses the driver's private data after calling spi_unregister_controller() even though that function releases the last reference on the spi_controller and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master/slave() helper which keeps the private data accessible until the driver has unbound. Fixes: 32e5b57232c0 ("spi: pxa2xx: Fix controller unregister order") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v2.6.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v2.6.17+: 32e5b57232c0: spi: pxa2xx: Fix controller unregister order Cc: <stable@vger.kernel.org> # v2.6.17+ Link: https://lore.kernel.org/r/5764b04d4a6e43069ebb7808f64c2f774ac6f193.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: spi-sh: Fix use-after-free on unbindLukas Wunner1-9/+4
spi_sh_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: 680c1305e259 ("spi/spi_sh: use spi_unregister_master instead of spi_master_put in remove path") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v3.0+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v3.0+ Cc: Axel Lin <axel.lin@ingics.com> Link: https://lore.kernel.org/r/6d97628b536baf01d5e3e39db61108f84d44c8b2.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: spi-qcom-qspi: Fix use-after-free on unbindLukas Wunner1-26/+16
qcom_qspi_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound. Fixes: f79a158d37c2 ("spi: spi-qcom-qspi: Use OPP API to set clk/perf state") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.9+ Cc: Rajendra Nayak <rnayak@codeaurora.org> Link: https://lore.kernel.org/r/b6d3c4dce571d78a532fd74f27def0d5dc8d8a24.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: spi-geni-qcom: Fix use-after-free on unbindLukas Wunner1-2/+1
spi_geni_remove() accesses the driver's private data after calling spi_unregister_master() even though that function releases the last reference on the spi_master and thereby frees the private data. Moreover, since commit 1a9e489e6128 ("spi: spi-geni-qcom: Use OPP API to set clk/perf state"), spi_geni_probe() leaks the spi_master allocation if the calls to dev_pm_opp_set_clkname() or dev_pm_opp_of_add_table() fail. Fix by switching over to the new devm_spi_alloc_master() helper which keeps the private data accessible until the driver has unbound and also avoids the spi_master leak on probe. Fixes: 561de45f72bd ("spi: spi-geni-qcom: Add SPI driver support for GENI based QUP") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v4.20+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v4.20+ Cc: Rajendra Nayak <rnayak@codeaurora.org> Cc: Girish Mahadevan <girishm@codeaurora.org> Link: https://lore.kernel.org/r/dfa1d8c41b8acdfad87ec8654cd124e6e3cb3f31.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: davinci: Fix use-after-free on unbindLukas Wunner1-1/+1
davinci_spi_remove() accesses the driver's private data after it's been freed with spi_master_put(). Fix by moving the spi_master_put() to the end of the function. Fixes: fe5fd2540947 ("spi: davinci: Use dma_request_chan() for requesting DMA channel") Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: <stable@vger.kernel.org> # v4.7+ Link: https://lore.kernel.org/r/412f7eb1cf8990e0a3a2153f4c577298deab623e.1607286887.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: atmel-quadspi: Move common code outside of if elseTudor Ambarus1-2/+2
QSPI_IFR is set as the last QSPI Instruction Frame register regardless of the sama5d2 or sam9x60 version of the IP. Move the writing of QSPI_IFR outside of the IP specific code. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201207135959.154124-5-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: atmel-quadspi: Write QSPI_IAR only when neededTudor Ambarus1-4/+4
The address must be written in QSPI_IAR only when we have a instruction frame with address but no data. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201207135959.154124-4-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: atmel-quadspi: Drop superfluous set of QSPI_IFR_APBTFRTYP_READTudor Ambarus1-3/+0
That bit describes the APB transfer type. We are writing serial memory registers via AHB acesses, that bit does not make sense in the current context. Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201207135959.154124-3-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: atmel-quadspi: Fix AHB memory accessesTudor Ambarus1-3/+7
Following error was seen when mounting a 16MByte ubifs: UBIFS error (ubi0:0 pid 1893): check_lpt_type.constprop.6: invalid type (15) in LPT node type QSPI_IFR.TFRTYP was not set correctly. When data transfer is enabled and one wants to access the serial memory through AHB in order to: - read in the serial memory, but not a memory data, for example a JEDEC-ID, QSPI_IFR.TFRTYP must be written to '0' (both sama5d2 and sam9x60). - read in the serial memory, and particularly a memory data, TFRTYP must be written to '1' (both sama5d2 and sam9x60). - write in the serial memory, but not a memory data, for example writing the configuration or the QSPI_SR, TFRTYP must be written to '2' for sama5d2 and to '0' for sam9x60. - write in the serial memory in particular to program a memory data, TFRTYP must be written to '3' for sama5d2 and to '1' for sam9x60. Fix the setting of the QSPI_IFR.TFRTYP field. Fixes: 2d30ac5ed633 ("mtd: spi-nor: atmel-quadspi: Use spi-mem interface for atmel-quadspi driver") Cc: <stable@vger.kernel.org> # v5.0+ Reported-by: Tom Burkart <tom@aussec.com> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com> Link: https://lore.kernel.org/r/20201207135959.154124-2-tudor.ambarus@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-07spi: dw: Fix error return code in dw_spi_bt1_probe()Zhang Changzhong1-1/+3
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/1607071357-33378-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-04spi: pxa2xx: Add support for Intel Alder Lake PCH-SJarkko Nikula1-0/+5
Add support for LPSS SPI on Intel Alder Lake. It has four LPSS SPI controllers each having two chip selects. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20201204082409.183700-1-jarkko.nikula@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-12-01spi: spi-fsl-dspi: Use max_native_cs instead of num_chipselect to set SPI_MCRMaxim Kochetkov1-3/+3
If cs-gpios property is used in devicetree then ctlr->num_chipselect value may be changed by spi_get_gpio_descs(). So use ctlr->max_native_cs instead of ctlr->num_chipselect to set SPI_MCR Fixes: 4fcc7c2292de (spi: spi-fsl-dspi: Don't access reserved fields in SPI_MCR) Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://lore.kernel.org/r/20201201085916.63543-1-fido_max@inbox.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-30spi: fsl: fix use of spisel_boot signal on MPC8309Rasmus Villemoes1-3/+8
Commit 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") broke the use of the SPISEL_BOOT signal as a chip select on the MPC8309. pdata->max_chipselect, which becomes master->num_chipselect, must be initialized to take into account the possibility that there's one more chip select in use than the number of GPIO chip selects. Cc: stable@vger.kernel.org # v5.4+ Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Linus Walleij <linus.walleij@linaro.org> Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk> Link: https://lore.kernel.org/r/20201127152947.376-1-rasmus.villemoes@prevas.dk Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-27Merge branch 'for-5.10' of ↵Mark Brown13-99/+117
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi into spi-5.11
2020-11-27spi: dw-bt1: Fix undefined devm_mux_control_get symbolSerge Semin1-2/+2
I mistakenly added the select attributes to the SPI_DW_BT1_DIRMAP config instead of having them defined in SPI_DW_BT1. If the kernel doesn't have the MULTIPLEXER and MUX_MMIO configs manually enabled and the SPI_DW_BT1_DIRMAP config hasn't been selected, Baikal-T1 SPI device will always fail to be probed by the driver. Fix that and the error reported by the test robot: >> ld.lld: error: undefined symbol: devm_mux_control_get >>> referenced by spi-dw-bt1.c >>> spi/spi-dw-bt1.o:(dw_spi_bt1_sys_init) in archive drivers/built-in.a by moving the MULTIPLEXER/MUX_MMIO configs selection to the SPI_DW_BT1 config. Link: https://lore.kernel.org/lkml/202011161745.uYRlekse-lkp@intel.com/ Link: https://lore.kernel.org/linux-spi/20201116040721.8001-1-rdunlap@infradead.org/ Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201127144612.4204-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-25spi: dw: fixed missing resource_sizeTian Tao1-1/+1
fixed the coccicheck: drivers/spi/spi-dw-bt1.c:220:27-30: ERROR: Missing resource_size with mem. Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/1606114975-31362-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-25spi: dw: Fix spi registration for controllers overriding CSLars Povlsen1-1/+2
When SPI DW memory ops support was introduced, there was a check for excluding controllers which supplied their own CS function. Even so, the mem_ops pointer is *always* presented to the SPI core. This causes the SPI core sanity check in spi_controller_check_ops() to refuse registration, since a mem_ops pointer is being supplied without an exec_op member function. The end result is failure of the SPI DW driver on sparx5 and similar platforms. The fix in the core SPI DW driver is to avoid presenting the mem_ops pointer if the exec_op function is not set. Fixes: 6423207e57ea (spi: dw: Add memory operations support) Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201120213414.339701-1-lars.povlsen@microchip.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-24spi: Fix potential NULL pointer dereference in spi_shutdown()Marek Szyprowski1-3/+5
Shutdown bus function might be called on the unbound device, so add a check if there is a driver before calling its shutdown function. This fixes following kernel panic obserbed during system reboot: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018 ... Call trace: spi_shutdown+0x10/0x38 kernel_restart_prepare+0x34/0x40 kernel_restart+0x14/0x88 __do_sys_reboot+0x148/0x248 __arm64_sys_reboot+0x1c/0x28 el0_svc_common.constprop.3+0x74/0x198 do_el0_svc+0x20/0x98 el0_sync_handler+0x140/0x1a8 el0_sync+0x140/0x180 Code: f9403402 d1008041 f100005f 9a9f1021 (f9400c21) ---[ end trace 266c07205a2d632e ]--- Fixes: 9db34ee64ce4 (spi: Use bus_type functions for probe, remove and shutdown) Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://lore.kernel.org/r/20201124131523.32287-1-m.szyprowski@samsung.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-24spi: imx: fix the unbalanced spi runtime pm managementClark Wang1-0/+1
If set active without increase the usage count of pm, the dont use autosuspend function will call the suspend callback to close the two clocks of spi because the usage count is reduced to -1. This will cause the warning dump below when the defer-probe occurs. [ 129.379701] ecspi2_root_clk already disabled [ 129.384005] WARNING: CPU: 1 PID: 33 at drivers/clk/clk.c:952 clk_core_disable+0xa4/0xb0 So add the get noresume function before set active. Fixes: 43b6bf406cd0 spi: imx: fix runtime pm support for !CONFIG_PM Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Link: https://lore.kernel.org/r/20201124085247.18025-1-xiaoning.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-23spi: amd: Use devm_platform_ioremap_resource() in amd_spi_probeQing Zhang1-4/+1
Simplify this function implementation by using a known wrapper function. Signed-off-by: Qing Zhang <zhangqing@loongson.cn> Link: https://lore.kernel.org/r/1605930231-19448-1-git-send-email-zhangqing@loongson.cn Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-23spi: spi-nxp-fspi: fix fspi panic by unexpected interruptsRan Wang1-0/+7
Given the case that bootloader(such as UEFI)'s FSPI driver might not handle all interrupts before loading kernel, those legacy interrupts would assert immidiately once kernel's FSPI driver enable them. Further, if it was FSPI_INTR_IPCMDDONE, the irq handler nxp_fspi_irq_handler() would call complete(&f->c) to notify others. However, f->c might not be initialized yet at that time, then cause kernel panic. Of cause, we should fix this issue within bootloader. But it would be better to have this pacth to make dirver more robust (by clearing all interrupt status bits before enabling interrupts). Suggested-by: Han Xu <han.xu@nxp.com> Signed-off-by: Ran Wang <ran.wang_1@nxp.com> Link: https://lore.kernel.org/r/20201123025715.14635-1-ran.wang_1@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-20spi: Take the SPI IO-mutex in the spi_setup() methodSerge Semin1-0/+5
I've discovered that due to the recent commit 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion") a concurrent usage of the spidev devices with different chip-selects causes the "SPI transfer timed out" error. The root cause of the problem has turned to be in a race condition of the SPI-transfer execution procedure and the spi_setup() method being called at the same time. In particular in calling the spi_set_cs(false) while there is an SPI-transfer being executed. In my case due to the commit cited above all CSs get to be switched off by calling the spi_setup() for /dev/spidev0.1 while there is an concurrent SPI-transfer execution performed on /dev/spidev0.0. Of course a situation of the spi_setup() being called while there is an SPI-transfer being executed for two different SPI peripheral devices of the same controller may happen not only for the spidev driver, but for instance for MMC SPI + some another device, or spi_setup() being called from an SPI-peripheral probe method while some other device has already been probed and is being used by a corresponding driver... Of course I could have provided a fix affecting the DW APB SSI driver only, for instance, by creating a mutual exclusive access to the set_cs callback and setting/clearing only the bit responsible for the corresponding chip-select. But after a short research I've discovered that the problem most likely affects a lot of the other drivers: - drivers/spi/spi-sun4i.c - RMW the chip-select register; - drivers/spi/spi-rockchip.c - RMW the chip-select register; - drivers/spi/spi-qup.c - RMW a generic force-CS flag in a CSR. - drivers/spi/spi-sifive.c - set a generic CS-mode flag in a CSR. - drivers/spi/spi-bcm63xx-hsspi.c - uses an internal mutex to serialize the bus config changes, but still isn't protected from the race condition described above; - drivers/spi/spi-geni-qcom.c - RMW a chip-select internal flag and set the CS state in HW; - drivers/spi/spi-orion.c - RMW a chip-select register; - drivers/spi/spi-cadence.c - RMW a chip-select register; - drivers/spi/spi-armada-3700.c - RMW a chip-select register; - drivers/spi/spi-lantiq-ssc.c - overwrites the chip-select register; - drivers/spi/spi-sun6i.c - RMW a chip-select register; - drivers/spi/spi-synquacer.c - RMW a chip-select register; - drivers/spi/spi-altera.c - directly sets the chip-select state; - drivers/spi/spi-omap2-mcspi.c - RMW an internally cached CS state and writes it to HW; - drivers/spi/spi-mt65xx.c - RMW some CSR; - drivers/spi/spi-jcore.c - directly sets the chip-selects state; - drivers/spi/spi-mt7621.c - RMW a chip-select register; I could have missed some drivers, but a scale of the problem is obvious. As you can see most of the drivers perform an unprotected Read-modify-write chip-select register modification in the set_cs callback. Seeing the spi_setup() function is calling the spi_set_cs() and it can be executed concurrently with SPI-transfers exec procedure, which also calls spi_set_cs() in the SPI core spi_transfer_one_message() method, the race condition of the register modification turns to be obvious. To sum up the problem denoted above affects each driver for a controller having more than one chip-select lane and which: 1) performs the RMW to some CS-related register with no serialization; 2) directly disables any CS on spi_set_cs(dev, false). * the later is the case of the DW APB SSI driver. The controllers which equipped with a single CS theoretically can also experience the problem, but in practice will not since normally the spi_setup() isn't called concurrently with the SPI-transfers executed on the same SPI peripheral device. In order to generically fix the denoted bug I'd suggest to serialize an access to the controller IO by taking the IO mutex in the spi_setup() callback. The mutex is held while there is an SPI communication going on on the SPI-bus of the corresponding SPI-controller. So calling the spi_setup() method and disabling/updating the CS state within it would be safe while there is no any SPI-transfers being executed. Also note I suppose it would be safer to protect the spi_controller->setup() callback invocation too, seeing some of the SPI-controller drivers update a HW state in there. Fixes: 49d7d695ca4b ("spi: dw: Explicitly de-assert CS on SPI transfer completion") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201117094517.5654-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-20spi: Warn when a driver's remove callback returns an errorUwe Kleine-König1-3/+10
The driver core ignores the return value of struct device_driver::remove (because in general there is nothing that can be done about that). So add a warning when an spi driver returns an error. This simplifies the quest to make struct device_driver::remove return void. A consequent change would be to make struct spi_driver::remove return void, but I'm keeping this quest for later (or someone else). Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119161604.2633521-3-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-20spi: Use bus_type functions for probe, remove and shutdownUwe Kleine-König1-17/+16
The eventual goal is to get rid of the callbacks in struct device_driver. Other than not using driver callbacks there should be no side effect of this patch. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119161604.2633521-2-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-20spi: fix resource leak for drivers without .remove callbackUwe Kleine-König1-9/+10
Consider an spi driver with a .probe but without a .remove callback (e.g. rtc-ds1347). The function spi_drv_probe() is called to bind a device and so dev_pm_domain_attach() is called. As there is no remove callback spi_drv_remove() isn't called at unbind time however and so calling dev_pm_domain_detach() is missed and the pm domain keeps active. To fix this always use both spi_drv_probe() and spi_drv_remove() and make them handle the respective callback not being set. This has the side effect that for a (hypothetical) driver that has neither .probe nor remove the clk and pm domain setup is done. Fixes: 33cf00e57082 ("spi: attach/detach SPI device to the ACPI power domain") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201119161604.2633521-1-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-18spi: mxs: fix reference leak in mxs_spi_probeZhang Qilong1-0/+1
pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in mxs_spi_probe, so we should fix it. Fixes: b7969caf41a1d ("spi: mxs: implement runtime pm") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201106012421.95420-1-zhangqilong3@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17spi: imx: Remove unused .id_table supportFabio Estevam1-30/+1
Since 5.10-rc1 i.MX is a devicetree-only platform and the existing .id_table support in this driver was only useful for old non-devicetree platforms. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201116202606.29888-1-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17spi: npcm-fiu: Don't leak SPI master in probe error pathLukas Wunner1-1/+1
If the calls to of_match_device(), of_alias_get_id(), devm_ioremap_resource(), devm_regmap_init_mmio() or devm_clk_get() fail on probe of the NPCM FIU SPI driver, the spi_controller struct is erroneously not freed. Fix by switching over to the new devm_spi_alloc_master() helper. Fixes: ace55c411b11 ("spi: npcm-fiu: add NPCM FIU controller driver") Signed-off-by: Lukas Wunner <lukas@wunner.de> Cc: <stable@vger.kernel.org> # v5.4+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation Cc: <stable@vger.kernel.org> # v5.4+ Cc: Tomer Maimon <tmaimon77@gmail.com> Link: https://lore.kernel.org/r/a420c23a363a3bc9aa684c6e790c32a8af106d17.1605512876.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17spi: dw: Set transfer handler before unmasking the IRQsSerge Semin1-2/+2
It turns out the IRQs most like can be unmasked before the controller is enabled with no problematic consequences. The manual doesn't explicitly state that, but the examples perform the controller initialization procedure in that order. So the commit da8f58909e7e ("spi: dw: Unmask IRQs after enabling the chip") hasn't been that required as I thought. But anyway setting the IRQs up after the chip enabling still worth adding since it has simplified the code a bit. The problem is that it has introduced a potential bug. The transfer handler pointer is now initialized after the IRQs are enabled. That may and eventually will cause an invalid or uninitialized callback invocation. Fix that just by performing the callback initialization before the IRQ unmask procedure. Fixes: da8f58909e7e ("spi: dw: Unmask IRQs after enabling the chip") Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru> Link: https://lore.kernel.org/r/20201117094054.4696-1-Sergey.Semin@baikalelectronics.ru Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-17Merge series "add axi clock control for MT8192 spi-nor" from Bayi Cheng ↵Mark Brown1-1/+15
<bayi.cheng@mediatek.com>: bayi cheng (1): spi: spi-mtk-nor: add axi clock control for MT8192 spi-nor drivers/spi/spi-mtk-nor.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) -- 1.9.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
2020-11-16spi: dw: fix build error by selecting MULTIPLEXERRandy Dunlap1-0/+1
Fix build error for spi-dw-bt1.o by selecting MULTIPLEXER. hppa-linux-ld: drivers/spi/spi-dw-bt1.o: in function `dw_spi_bt1_sys_init': (.text+0x1ac): undefined reference to `devm_mux_control_get' Fixes: abf00907538e ("spi: dw: Add Baikal-T1 SPI Controller glue driver") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Ramil Zaripov <Ramil.Zaripov@baikalelectronics.ru> Cc: Mark Brown <broonie@kernel.org> Cc: linux-spi@vger.kernel.org Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20201116040721.8001-1-rdunlap@infradead.org Signed-off-by: Mark Brown <broonie@kernel.org>
2020-11-16spi: spi-mtk-nor: add axi clock control for MT8192 spi-norbayi cheng1-1/+15
MT8192 spi-nor is an independent sub system, we need extra control axi bus clock for it. Add support for the additional axi clock to allow it to be configured appropriately. Signed-off-by: bayi cheng <bayi.cheng@mediatek.com> Tested-by: Ikjoon Jang <ikjn@chromium.org> Link: https://lore.kernel.org/r/1605084902-13151-2-git-send-email-bayi.cheng@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-15 12:22:49 +0300