summaryrefslogtreecommitdiff
path: root/drivers/spi
AgeCommit message (Collapse)AuthorFilesLines
2020-01-09spi: uniphier: Fix FIFO thresholdKunihiko Hayashi1-12/+19
commit 9cd34efbd3012171c102910ce17ee632a3cccb44 upstream. Rx threshold means the value to inform the receiver when the number of words in Rx FIFO is equal to or more than the value. Similarly, Tx threshold means the value to inform the sender when the number of words in Tx FIFO is equal to or less than the value. The controller triggers the driver to start the transfer. In case of Rx, the driver wants to detect that the specified number of words N are in Rx FIFO, so the value of Rx threshold should be N. In case of Tx, the driver wants to detect that the same number of spaces as Rx are in Tx FIFO, so the value of Tx threshold should be (FIFO size - N). For example, in order for the driver to receive at least 3 words from Rx FIFO, set 3 to Rx threshold. +-+-+-+-+-+-+-+-+ | | | | | |*|*|*| +-+-+-+-+-+-+-+-+ In order for the driver to send at least 3 words to Tx FIFO, because it needs at least 3 spaces, set 8(FIFO size) - 3 = 5 to Tx threshold. +-+-+-+-+-+-+-+-+ |*|*|*|*|*| | | | +-+-+-+-+-+-+-+-+ This adds new function uniphier_spi_set_fifo_threshold() to set threshold value to the register. And more, FIFO counts by 'words', so this renames 'fill_bytes' with 'fill_words', and fixes the calculation using bytes_per_words. Fixes: 37ffab817098 ("spi: uniphier: introduce polling mode") Cc: Keiji Hayashibara <hayashibara.keiji@socionext.com> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1577149107-30670-2-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-09spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI modeVladimir Oltean1-11/+4
commit ca59d5a51690d5b9340343dc36792a252e9414ae upstream. When used in Extended SPI mode on LS1021A, the DSPI controller wants to have the least significant 16-bit word written first to the TX FIFO. In fact, the LS1021A reference manual says: 33.5.2.4.2 Draining the TX FIFO When Extended SPI Mode (DSPIx_MCR[XSPI]) is enabled, if the frame size of SPI Data to be transmitted is more than 16 bits, then it causes two Data entries to be popped from TX FIFO simultaneously which are transferred to the shift register. The first of the two popped entries forms the 16 least significant bits of the SPI frame to be transmitted. So given the following TX buffer: +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 0x0 | 0x1 | 0x2 | 0x3 | 0x4 | 0x5 | 0x6 | 0x7 | 0x8 | 0x9 | 0xa | 0xb | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | 32-bit word 1 | 32-bit word 2 | 32-bit word 3 | +-----------------------+-----------------------+-----------------------+ The correct way that a little-endian system should transmit it on the wire when bits_per_word is 32 is: 0x03020100 0x07060504 0x0b0a0908 But it is actually transmitted as following, as seen with a scope: 0x01000302 0x05040706 0x09080b0a It appears that this patch has been submitted at least once before: https://lkml.org/lkml/2018/9/21/286 but in that case Chuanhua Han did not manage to explain the problem clearly enough and the patch did not get merged, leaving XSPI mode broken. Fixes: 8fcd151d2619 ("spi: spi-fsl-dspi: XSPI FIFO handling (in TCFQ mode)") Cc: Esben Haabendal <eha@deif.com> Cc: Chuanhua Han <chuanhua.han@nxp.com> Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20191228135536.14284-1-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-31spi: fsl: use platform_get_irq() instead of of_irq_to_resource()Christophe Leroy1-3/+3
commit 63aa6a692595d47a0785297b481072086b9272d2 upstream. Unlike irq_of_parse_and_map() which has a dummy definition on SPARC, of_irq_to_resource() hasn't. But as platform_get_irq() can be used instead and is generic, use it. Reported-by: kbuild test robot <lkp@intel.com> Suggested-by: Mark Brown <broonie@kernel.org> Fixes: 3194d2533eff ("spi: fsl: don't map irq during probe") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Link: https://lore.kernel.org/r/091a277fd0b3356dca1e29858c1c96983fc9cb25.1576172743.git.christophe.leroy@c-s.fr Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-31spi: fsl: don't map irq during probeChristophe Leroy1-3/+2
commit 3194d2533efffae8b815d84729ecc58b6a9000ab upstream. With lastest kernel, the following warning is observed at startup: [ 1.500609] ------------[ cut here ]------------ [ 1.505225] remove_proc_entry: removing non-empty directory 'irq/22', leaking at least 'fsl_spi' [ 1.514234] WARNING: CPU: 0 PID: 1 at fs/proc/generic.c:682 remove_proc_entry+0x198/0x1c0 [ 1.522403] CPU: 0 PID: 1 Comm: swapper Not tainted 5.4.0-s3k-dev-02248-g93532430a4ff #2564 [ 1.530724] NIP: c0197694 LR: c0197694 CTR: c0050d80 [ 1.535762] REGS: df4a5af0 TRAP: 0700 Not tainted (5.4.0-02248-g93532430a4ff) [ 1.543818] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 22028222 XER: 00000000 [ 1.550524] [ 1.550524] GPR00: c0197694 df4a5ba8 df4a0000 00000054 00000000 00000000 00004a38 00000010 [ 1.550524] GPR08: c07c5a30 00000800 00000000 00001032 22000208 00000000 c0004b14 00000000 [ 1.550524] GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 c0830000 c07fc078 [ 1.550524] GPR24: c08e8ca0 df665d10 df60ea98 c07c9db8 00000001 df5d5ae3 df5d5a80 df43f8e3 [ 1.585327] NIP [c0197694] remove_proc_entry+0x198/0x1c0 [ 1.590628] LR [c0197694] remove_proc_entry+0x198/0x1c0 [ 1.595829] Call Trace: [ 1.598280] [df4a5ba8] [c0197694] remove_proc_entry+0x198/0x1c0 (unreliable) [ 1.605321] [df4a5bd8] [c0067acc] unregister_irq_proc+0x5c/0x70 [ 1.611238] [df4a5bf8] [c005fbc4] free_desc+0x3c/0x80 [ 1.616286] [df4a5c18] [c005fe2c] irq_free_descs+0x70/0xa8 [ 1.621778] [df4a5c38] [c033d3fc] of_fsl_spi_probe+0xdc/0x3cc [ 1.627525] [df4a5c88] [c02f0f64] platform_drv_probe+0x44/0xa4 [ 1.633350] [df4a5c98] [c02eee44] really_probe+0x1ac/0x418 [ 1.638829] [df4a5cc8] [c02ed3e8] bus_for_each_drv+0x64/0xb0 [ 1.644481] [df4a5cf8] [c02ef950] __device_attach+0xd4/0x128 [ 1.650132] [df4a5d28] [c02ed61c] bus_probe_device+0xa0/0xbc [ 1.655783] [df4a5d48] [c02ebbe8] device_add+0x544/0x74c [ 1.661096] [df4a5d88] [c0382b78] of_platform_device_create_pdata+0xa4/0x100 [ 1.668131] [df4a5da8] [c0382cf4] of_platform_bus_create+0x120/0x20c [ 1.674474] [df4a5df8] [c0382d50] of_platform_bus_create+0x17c/0x20c [ 1.680818] [df4a5e48] [c0382e88] of_platform_bus_probe+0x9c/0xf0 [ 1.686907] [df4a5e68] [c0751404] __machine_initcall_cmpcpro_cmpcpro_declare_of_platform_devices+0x74/0x1a4 [ 1.696629] [df4a5e98] [c072a4cc] do_one_initcall+0x8c/0x1d4 [ 1.702282] [df4a5ef8] [c072a768] kernel_init_freeable+0x154/0x204 [ 1.708455] [df4a5f28] [c0004b2c] kernel_init+0x18/0x110 [ 1.713769] [df4a5f38] [c00122ac] ret_from_kernel_thread+0x14/0x1c [ 1.719926] Instruction dump: [ 1.722889] 2c030000 4182004c 3863ffb0 3c80c05f 80e3005c 388436a0 3c60c06d 7fa6eb78 [ 1.730630] 7fe5fb78 38840280 38634178 4be8c611 <0fe00000> 4bffff6c 3c60c071 7fe4fb78 [ 1.738556] ---[ end trace 05d0720bf2e352e2 ]--- The problem comes from the error path which calls irq_dispose_mapping() while the IRQ has been requested with devm_request_irq(). IRQ doesn't need to be mapped with irq_of_parse_and_map(). The only need is to get the IRQ virtual number. For that, use of_irq_to_resource() instead of the irq_of_parse_and_map()/irq_dispose_mapping() pair. Fixes: 500a32abaf81 ("spi: fsl: Call irq_dispose_mapping in err path") Cc: stable@vger.kernel.org Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr> Link: https://lore.kernel.org/r/518cfb83347d5372748e7fe72f94e2e9443d0d4a.1575905123.git.christophe.leroy@c-s.fr Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-31spi: cadence: Correct handling of native chipselectCharles Keepax1-3/+3
[ Upstream commit 61acd19f9c56fa0809285346bd0bd4a926ab0da0 ] To fix a regression on the Cadence SPI driver, this patch reverts commit 6046f5407ff0 ("spi: cadence: Fix default polarity of native chipselect"). This patch was not the correct fix for the issue. The SPI framework calls the set_cs line with the logic level it desires on the chip select line, as such the old is_high handling was correct. However, this was broken by the fact that before commit 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") all controllers that offered the use of a GPIO chip select had SPI_CS_HIGH applied, even for hardware chip selects. This caused the value passed into the driver to be inverted. Which unfortunately makes it look like a logical enable the chip select value. Since the core was corrected to not unconditionally apply SPI_CS_HIGH, the Cadence driver, whilst using the hardware chip select, will deselect the chip select every time we attempt to communicate with the device, which results in failed communications. Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191126164140.6240-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: dw: Correct handling of native chipselectCharles Keepax1-2/+3
[ Upstream commit ada9e3fcc175db4538f5b5e05abf5dedf626e550 ] This patch reverts commit 6e0a32d6f376 ("spi: dw: Fix default polarity of native chipselect"). The SPI framework always called the set_cs callback with the logic level it desired on the chip select line, which is what the drivers original handling supported. commit f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") changed these symantics, but only in the case of drivers that also support GPIO chip selects, to true meaning apply slave select rather than logic high. This left things in an odd state where a driver that only supports hardware chip selects, the core would handle polarity but if the driver supported GPIOs as well the driver should handle polarity. At this point the reverted change was applied to change the logic in the driver to match new system. This was then broken by commit 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") which reverted the core back to consistently calling set_cs with a logic level. This fix reverts the driver code back to its original state to match the current core code. This is probably a better fix as a) the set_cs callback is always called with consistent symantics and b) the inversion for SPI_CS_HIGH can be handled in the core and doesn't need to be coded in each driver supporting it. Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20191127153936.29719-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: st-ssc4: add missed pm_runtime_disableChuhong Yuan1-0/+3
[ Upstream commit cd050abeba2a95fe5374eec28ad2244617bcbab6 ] The driver forgets to call pm_runtime_disable in probe failure and remove. Add the missed calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191118024848.21645-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: tegra20-slink: add missed clk_unprepareChuhong Yuan1-1/+4
[ Upstream commit 04358e40ba96d687c0811c21d9dede73f5244a98 ] The driver misses calling clk_unprepare in probe failure and remove. Add the calls to fix it. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191115083122.12278-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: pxa2xx: Add missed security checksChuhong Yuan1-0/+6
[ Upstream commit 5eb263ef08b5014cfc2539a838f39d2fd3531423 ] pxa2xx_spi_init_pdata misses checks for devm_clk_get and platform_get_irq. Add checks for them to fix the bugs. Since ssp->clk and ssp->irq are used in probe, they are mandatory here. So we cannot use _optional() for devm_clk_get and platform_get_irq. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20191109080943.30428-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: img-spfi: fix potential double releasePan Bian1-0/+2
[ Upstream commit e9a8ba9769a0e354341bc6cc01b98aadcea1dfe9 ] The channels spfi->tx_ch and spfi->rx_ch are not set to NULL after they are released. As a result, they will be released again, either on the error handling branch in the same function or in the corresponding remove function, i.e. img_spfi_remove(). This patch fixes the bug by setting the two members to NULL. Signed-off-by: Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/1573007769-20131-1-git-send-email-bianpan2016@163.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: dw: Fix Designware SPI loopbackThor Thayer1-1/+2
[ Upstream commit 1403cfa69d310781f9548951c97725c67ffcf613 ] The SPI_LOOP is set in spi->mode but not propagated to the register. A previous patch removed the bit during a cleanup. Fixes: e1bc204894ea ("spi: dw: fix potential variable assignment error") Signed-off-by: Thor Thayer <thor.thayer@linux.intel.com> Link: https://lore.kernel.org/r/1572985330-5525-1-git-send-email-thor.thayer@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: sifive: disable clk when probe fails and removeChuhong Yuan1-4/+7
[ Upstream commit a725272bda77e61c1b4de85c7b0c875b2ea639b6 ] The driver forgets to disable and unprepare clk when probe fails and remove. Add the calls to fix the problem. Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Reviewed-by: Palmer Dabbelt <palmer@dabbelt.com> Link: https://lore.kernel.org/r/20191101121745.13413-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: sprd: adi: Add missing lock protection when rebootingLingling Xu1-0/+3
[ Upstream commit 91ea1d70607e374b014b4b9bea771ce661f9f64b ] When rebooting the system, we should lock the watchdog after configuration to make sure the watchdog can reboot the system successfully. Signed-off-by: Lingling Xu <ling_ling.xu@unisoc.com> Signed-off-by: Baolin Wang <baolin.wang@linaro.org> Link: https://lore.kernel.org/r/7b04711127434555e3a1a86bc6be99860cd86668.1572257085.git.baolin.wang@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: gpio: prevent memory leak in spi_gpio_probeNavid Emamdoost1-1/+3
[ Upstream commit d3b0ffa1d75d5305ebe34735598993afbb8a869d ] In spi_gpio_probe an SPI master is allocated via spi_alloc_master, but this controller should be released if devm_add_action_or_reset fails, otherwise memory leaks. In order to avoid leak spi_contriller_put must be called in case of failure for devm_add_action_or_reset. Fixes: 8b797490b4db ("spi: gpio: Make sure spi_master_put() is called in every error path") Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Link: https://lore.kernel.org/r/20190930205241.5483-1-navid.emamdoost@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-31spi: Add call to spi_slave_abort() function when spidev driver is releasedLukasz Majewski1-0/+3
[ Upstream commit 9f918a728cf86b2757b6a7025e1f46824bfe3155 ] This change is necessary for spidev devices (e.g. /dev/spidev3.0) working in the slave mode (like NXP's dspi driver for Vybrid SoC). When SPI HW works in this mode - the master is responsible for providing CS and CLK signals. However, when some fault happens - like for example distortion on SPI lines - the SPI Linux driver needs a chance to recover from this abnormal situation and prepare itself for next (correct) transmission. This change doesn't pose any threat on drivers working in master mode as spi_slave_abort() function checks if SPI slave mode is supported. Signed-off-by: Lukasz Majewski <lukma@denx.de> Link: https://lore.kernel.org/r/20190924110547.14770-2-lukma@denx.de Signed-off-by: Mark Brown <broonie@kernel.org> Reported-by: kbuild test robot <lkp@intel.com> Link: https://lore.kernel.org/r/20190925091143.15468-2-lukma@denx.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-12-13spi: Fix NULL pointer when setting SPI_CS_HIGH for GPIO CSGregory CLEMENT1-1/+2
commit 15f794bd977a0135328fbdd8a83cc64c1d267b39 upstream. Even if the flag use_gpio_descriptors is set, it is possible that cs_gpiods was not allocated, which leads to a kernel crash. Reported-by: "kernelci.org bot" <bot@kernelci.org> Fixes: 3e5ec1db8bfe ("spi: Fix SPI_CS_HIGH setting when using native and GPIO CS") Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20191024141309.22434-1-gregory.clement@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-13spi: Fix SPI_CS_HIGH setting when using native and GPIO CSGregory CLEMENT1-9/+9
commit 3e5ec1db8bfee845d9f8560d1c64aeaccd586398 upstream. When improving the CS GPIO support at core level, the SPI_CS_HIGH has been enabled for all the CS lines used for a given SPI controller. However, the SPI framework allows to have on the same controller native CS and GPIO CS. The native CS may not support the SPI_CS_HIGH, so they should not be setup automatically. With this patch the setting is done only for the CS that will use a GPIO as CS Fixes: f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs") Cc: <stable@vger.kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20191018152929.3287-1-gregory.clement@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-13spi: atmel: Fix CS high supportGregory CLEMENT1-4/+2
commit 7cbb16b2122c09f2ae393a1542fed628505b9da6 upstream. Until a few years ago, this driver was only used with CS GPIO. The only exception is CS0 on AT91RM9200 which has to use internal CS. A limitation of the internal CS is that they don't support CS High. So by using the CS GPIO the CS high configuration was available except for the particular case CS0 on RM9200. When the support for the internal chip-select was added, the check of the CS high support was not updated. Due to this the driver accepts this configuration for all the SPI controller v2 (used by all SoCs excepting the AT91RM9200) whereas the hardware doesn't support it for infernal CS. This patch fixes the test to match the hardware capabilities. Fixes: 4820303480a1 ("spi: atmel: add support for the internal chip-select of the spi controller") Cc: <stable@vger.kernel.org> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Link: https://lore.kernel.org/r/20191017141846.7523-3-gregory.clement@bootlin.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-13spi: stm32-qspi: Fix kernel oops when unbinding driverPatrice Chotard1-1/+2
commit 3c0af1dd2fe78adc02fe21f6cfe7d6cb8602573e upstream. spi_master_put() must only be called in .probe() in case of error. As devm_spi_register_master() is used during probe, spi_master_put() mustn't be called in .remove() callback. It fixes the following kernel WARNING/Oops when executing echo "58003000.spi" > /sys/bus/platform/drivers/stm32-qspi/unbind : ------------[ cut here ]------------ WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4 kernfs: can not remove 'uevent', no directory Modules linked in: CPU: 1 PID: 496 Comm: sh Not tainted 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) [<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14) [<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8) [<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8) [<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c) [<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4) [<c02e5844>] (kernfs_remove_by_name_ns) from [<c05833a4>] (device_del+0x128/0x358) [<c05833a4>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64) [<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8) [<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200) [<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac) [<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4) [<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4) [<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0) [<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184) [<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0) [<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xdd289fa8 to 0xdd289ff0) 9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 ---[ end trace 1b15df8a02d76aef ]--- ------------[ cut here ]------------ WARNING: CPU: 1 PID: 496 at fs/kernfs/dir.c:1504 kernfs_remove_by_name_ns+0x9c/0xa4 kernfs: can not remove 'online', no directory Modules linked in: CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) [<c0111570>] (unwind_backtrace) from [<c010d384>] (show_stack+0x10/0x14) [<c010d384>] (show_stack) from [<c08db558>] (dump_stack+0xb4/0xc8) [<c08db558>] (dump_stack) from [<c01209d8>] (__warn.part.3+0xbc/0xd8) [<c01209d8>] (__warn.part.3) from [<c0120a5c>] (warn_slowpath_fmt+0x68/0x8c) [<c0120a5c>] (warn_slowpath_fmt) from [<c02e5844>] (kernfs_remove_by_name_ns+0x9c/0xa4) [<c02e5844>] (kernfs_remove_by_name_ns) from [<c0582488>] (device_remove_attrs+0x20/0x5c) [<c0582488>] (device_remove_attrs) from [<c05833b0>] (device_del+0x134/0x358) [<c05833b0>] (device_del) from [<c05835f8>] (device_unregister+0x24/0x64) [<c05835f8>] (device_unregister) from [<c0638dac>] (spi_unregister_controller+0x88/0xe8) [<c0638dac>] (spi_unregister_controller) from [<c058c580>] (release_nodes+0x1bc/0x200) [<c058c580>] (release_nodes) from [<c0588a44>] (device_release_driver_internal+0xec/0x1ac) [<c0588a44>] (device_release_driver_internal) from [<c0586840>] (unbind_store+0x60/0xd4) [<c0586840>] (unbind_store) from [<c02e64e8>] (kernfs_fop_write+0xe8/0x1c4) [<c02e64e8>] (kernfs_fop_write) from [<c0266b44>] (__vfs_write+0x2c/0x1c0) [<c0266b44>] (__vfs_write) from [<c02694c0>] (vfs_write+0xa4/0x184) [<c02694c0>] (vfs_write) from [<c0269710>] (ksys_write+0x58/0xd0) [<c0269710>] (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x54) Exception stack(0xdd289fa8 to 0xdd289ff0) 9fa0: 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 ---[ end trace 1b15df8a02d76af0 ]--- 8<--- cut here --- Unable to handle kernel NULL pointer dereference at virtual address 00000050 pgd = e612f14d [00000050] *pgd=ff1f5835 Internal error: Oops: 17 [#1] SMP ARM Modules linked in: CPU: 1 PID: 496 Comm: sh Tainted: G W 5.3.0-rc1-00219-ga0e07bb51a37 #62 Hardware name: STM32 (Device Tree Support) PC is at kernfs_find_ns+0x8/0xfc LR is at kernfs_find_and_get_ns+0x30/0x48 pc : [<c02e49a4>] lr : [<c02e4ac8>] psr: 40010013 sp : dd289dac ip : 00000000 fp : 00000000 r10: 00000000 r9 : def6ec58 r8 : dd289e54 r7 : 00000000 r6 : c0abb234 r5 : 00000000 r4 : c0d26a30 r3 : ddab5080 r2 : 00000000 r1 : c0abb234 r0 : 00000000 Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: dd11c06a DAC: 00000051 Process sh (pid: 496, stack limit = 0xe13a592d) Stack: (0xdd289dac to 0xdd28a000) 9da0: c0d26a30 00000000 c0abb234 00000000 c02e4ac8 9dc0: 00000000 c0976b44 def6ec00 dea53810 dd289e54 c02e864c c0a61a48 c0a4a5ec 9de0: c0d630a8 def6ec00 c0d04c48 c02e86e0 def6ec00 de909338 c0d04c48 c05833b0 9e00: 00000000 c0638144 dd289e54 def59900 00000000 475b3ee5 def6ec00 00000000 9e20: def6ec00 def59b80 dd289e54 def59900 00000000 c05835f8 def6ec00 c0638dac 9e40: 0000000a dea53810 c0d04c48 c058c580 dea53810 def59500 def59b80 475b3ee5 9e60: ddc63e00 dea53810 dea3fe10 c0d63a0c dea53810 ddc63e00 dd289f78 dd240d10 9e80: 00000000 c0588a44 c0d59a20 0000000d c0d63a0c c0586840 0000000d dd240d00 9ea0: 00000000 00000000 ddc63e00 c02e64e8 00000000 00000000 c0d04c48 dd9bbcc0 9ec0: c02e6400 dd289f78 00000000 000e20e8 0000000d c0266b44 00000055 00000cc0 9ee0: 000000e3 000e3000 dd11c000 dd11c000 00000000 00000000 00000000 00000000 9f00: ffeee38c dff99688 00000000 475b3ee5 00000001 dd289fb0 ddab5080 ddaa5800 9f20: 00000817 000e30ec dd9e7720 475b3ee5 ddaa583c 0000000d dd9bbcc0 000e20e8 9f40: dd289f78 00000000 000e20e8 0000000d 00000000 c02694c0 00000000 00000000 9f60: c0d04c48 dd9bbcc0 00000000 00000000 dd9bbcc0 c0269710 00000000 00000000 9f80: 000a91f4 475b3ee5 0000006c 000e20e8 b6f87da0 00000004 c0101204 dd288000 9fa0: 00000004 c0101000 0000006c 000e20e8 00000001 000e20e8 0000000d 00000000 9fc0: 0000006c 000e20e8 b6f87da0 00000004 0000000d 0000000d 00000000 00000000 9fe0: 00000004 bee639b0 b6f2286b b6eaf6c6 600e0030 00000001 00000000 00000000 [<c02e49a4>] (kernfs_find_ns) from [<def6ec00>] (0xdef6ec00) Code: ebf8eeab c0dc50b8 e92d40f0 e292c000 (e1d035b0) ---[ end trace 1b15df8a02d76af1 ]--- Fixes: a88eceb17ac7 ("spi: stm32-qspi: add spi_master_put in release function") Cc: <stable@vger.kernel.org> Signed-off-by: Patrice Chotard <patrice.chotard@st.com> Link: https://lore.kernel.org/r/20191004123606.17241-1-patrice.chotard@st.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-13spi: spi-fsl-qspi: Clear TDH bits in FLSHCR registerFrieder Schrempf1-5/+33
commit f6910679e17ad4915f008bd2c614d38052426f7c upstream. Later versions of the QSPI controller (e.g. in i.MX6UL/ULL and i.MX7) seem to have an additional TDH setting in the FLSHCR register, that needs to be set in accordance with the access mode that is used (DDR or SDR). Previous bootstages such as BootROM or bootloader might have used the DDR mode to access the flash. As we currently only use SDR mode, we need to make sure the TDH bits are cleared upon initialization. Fixes: 84d043185dbe ("spi: Add a driver for the Freescale/NXP QuadSPI controller") Cc: <stable@vger.kernel.org> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Acked-by: Han Xu <han.xu@nxp.com> Link: https://lore.kernel.org/r/20191007071933.26786-1-frieder.schrempf@kontron.de Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-18Merge tag 'leds-for-5.4-rc1' of ↵Linus Torvalds1-23/+5
git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds Pull LED updates from Jacek Anaszewski: "In this cycle we've finally managed to contribute the patch set sorting out LED naming issues. Besides that there are many changes scattered among various LED class drivers and triggers. LED naming related improvements: - add new 'function' and 'color' fwnode properties and deprecate 'label' property which has been frequently abused for conveying vendor specific names that have been available in sysfs anyway - introduce a set of standard LED_FUNCTION* definitions - introduce a set of standard LED_COLOR_ID* definitions - add a new {devm_}led_classdev_register_ext() API with the capability of automatic LED name composition basing on the properties available in the passed fwnode; the function is backwards compatible in a sense that it uses 'label' data, if present in the fwnode, for creating LED name - add tools/leds/get_led_device_info.sh script for retrieving LED vendor, product and bus names, if applicable; it also performs basic validation of an LED name - update following drivers and their DT bindings to use the new LED registration API: - leds-an30259a, leds-gpio, leds-as3645a, leds-aat1290, leds-cr0014114, leds-lm3601x, leds-lm3692x, leds-lp8860, leds-lt3593, leds-sc27xx-blt Other LED class improvements: - replace {devm_}led_classdev_register() macros with inlines - allow to call led_classdev_unregister() unconditionally - switch to use fwnode instead of be stuck with OF one LED triggers improvements: - led-triggers: - fix dereferencing of null pointer - fix a memory leak bug - ledtrig-gpio: - GPIO 0 is valid Drop superseeded apu2/3 support from leds-apu since for apu2+ a newer, more complete driver exists, based on a generic driver for the AMD SOCs gpio-controller, supporting LEDs as well other devices: - drop profile field from priv data - drop iosize field from priv data - drop enum_apu_led_platform_types - drop superseeded apu2/3 led support - add pr_fmt prefix for better log output - fix error message on probing failure Other misc fixes and improvements to existing LED class drivers: - leds-ns2, leds-max77650: - add of_node_put() before return - leds-pwm, leds-is31fl32xx: - use struct_size() helper - leds-lm3697, leds-lm36274, leds-lm3532: - switch to use fwnode_property_count_uXX() - leds-lm3532: - fix brightness control for i2c mode - change the define for the fs current register - fixes for the driver for stability - add full scale current configuration - dt: Add property for full scale current. - avoid potentially unpaired regulator calls - move static keyword to the front of declarations - fix optional led-max-microamp prop error handling - leds-max77650: - add of_node_put() before return - add MODULE_ALIAS() - Switch to fwnode property API - leds-as3645a: - fix misuse of strlcpy - leds-netxbig: - add of_node_put() in netxbig_leds_get_of_pdata() - remove legacy board-file support - leds-is31fl319x: - simplify getting the adapter of a client - leds-ti-lmu-common: - fix coccinelle issue - move static keyword to the front of declaration - leds-syscon: - use resource managed variant of device register - leds-ktd2692: - fix a typo in the name of a constant - leds-lp5562: - allow firmware files up to the maximum length - leds-an30259a: - fix typo - leds-pca953x: - include the right header" * tag 'leds-for-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: (72 commits) leds: lm3532: Fix optional led-max-microamp prop error handling led: triggers: Fix dereferencing of null pointer leds: ti-lmu-common: Move static keyword to the front of declaration leds: lm3532: Move static keyword to the front of declarations leds: trigger: gpio: GPIO 0 is valid leds: pwm: Use struct_size() helper leds: is31fl32xx: Use struct_size() helper leds: ti-lmu-common: Fix coccinelle issue in TI LMU leds: lm3532: Avoid potentially unpaired regulator calls leds: syscon: Use resource managed variant of device register leds: Replace {devm_}led_classdev_register() macros with inlines leds: Allow to call led_classdev_unregister() unconditionally leds: lm3532: Add full scale current configuration dt: lm3532: Add property for full scale current. leds: lm3532: Fixes for the driver for stability leds: lm3532: Change the define for the fs current register leds: lm3532: Fix brightness control for i2c mode leds: Switch to use fwnode instead of be stuck with OF one leds: max77650: Switch to fwnode property API led: triggers: Fix a memory leak bug ...
2019-09-18Merge tag 'docs-5.4' of git://git.lwn.net/linuxLinus Torvalds3-3/+3
Pull documentation updates from Jonathan Corbet: "It's a somewhat calmer cycle for docs this time, as the churn of the mass RST conversion is happily mostly behind us. - A new document on reproducible builds. - We finally got around to zapping the documentation for hardware support that was removed in 2004; one doesn't want to rush these things. - The usual assortment of fixes, typo corrections, etc" * tag 'docs-5.4' of git://git.lwn.net/linux: (67 commits) Documentation: kbuild: Add document about reproducible builds docs: printk-formats: Stop encouraging use of unnecessary %h[xudi] and %hh[xudi] Documentation: Add "earlycon=sbi" to the admin guide doc:lock: remove reference to clever use of read-write lock devices.txt: improve entry for comedi (char major 98) docs: mtd: Update spi nor reference driver doc: arm64: fix grammar dtb placed in no attributes region Documentation: sysrq: don't recommend 'S' 'U' before 'B' mailmap: Update email address for Quentin Perret docs: ftrace: clarify when tracing is disabled by the trace file docs: process: fix broken link Documentation/arm/samsung-s3c24xx: Remove stray U+FEFF character to fix title Documentation/arm/sa1100/assabet: Fix 'make assabet_defconfig' command Documentation/arm/sa1100: Remove some obsolete documentation docs/zh_CN: update Chinese howto.rst for latexdocs making Documentation: virt: Fix broken reference to virt tree's index docs: Fix typo on pull requests guide kernel-doc: Allow anonymous enum Documentation: sphinx: Don't parse socket() as identifier reference Documentation: sphinx: Add missing comma to list of strings ...
2019-09-17Merge tag 'armsoc-drivers' of ↵Linus Torvalds3-434/+0
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "This contains driver changes that are tightly connected to SoC specific code. Aside from smaller cleanups and bug fixes, here is a list of the notable changes. New device drivers: - The Turris Mox router has a new "moxtet" bus driver for its on-board pluggable extension bus. The same platform also gains a firmware driver. - The Samsung Exynos family gains a new Chipid driver exporting using the soc device sysfs interface - A similar socinfo driver for Qualcomm Snapdragon chips. - A firmware driver for the NXP i.MX DSP IPC protocol using shared memory and a mailbox Other changes: - The i.MX reset controller driver now supports the NXP i.MX8MM chip - Amlogic SoC specific drivers gain support for the S905X3 and A311D chips - A rework of the TI Davinci framebuffer driver to allow important cleanups in the platform code - A couple of device drivers for removed ARM SoC platforms are removed. Most of the removals were picked up by other maintainers, this contains whatever was left" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (123 commits) bus: uniphier-system-bus: use devm_platform_ioremap_resource() soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access firmware: ti_sci: Allow for device shared and exclusive requests bus: imx-weim: remove incorrect __init annotations fbdev: remove w90x900/nuc900 platform drivers spi: remove w90x900 driver net: remove w90p910-ether driver net: remove ks8695 driver firmware: turris-mox-rwtm: Add sysfs documentation firmware: Add Turris Mox rWTM firmware driver dt-bindings: firmware: Document cznic,turris-mox-rwtm binding bus: moxtet: fix unsigned comparison to less than zero bus: moxtet: remove set but not used variable 'dummy' ARM: scoop: Use the right include dt-bindings: power: add Amlogic Everything-Else power domains bindings soc: amlogic: Add support for Everything-Else power domains controller fbdev: da8xx: use resource management for dma fbdev: da8xx-fb: drop a redundant if fbdev: da8xx-fb: use devm_platform_ioremap_resource() ...
2019-09-15Merge branch 'spi-5.4' into spi-nextMark Brown64-887/+1817
2019-09-15Merge branch 'spi-5.3' into spi-linusMark Brown6-6/+33
2019-09-13spi: mediatek: support large PAluhua.xu1-5/+39
Add spi large PA(max=64G) support for DMA transfer. Signed-off-by: luhua.xu <luhua.xu@mediatek.com> Link: https://lore.kernel.org/r/1568195731-3239-4-git-send-email-luhua.xu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-13spi: mediatek: add spi support for mt6765 ICluhua.xu1-0/+9
This patch add spi support for mt6765 IC. Signed-off-by: luhua.xu <luhua.xu@mediatek.com> Link: https://lore.kernel.org/r/1568195731-3239-3-git-send-email-luhua.xu@mediatek.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Speed up RX-only DMA transfers by zero-filling TX FIFOLukas Wunner1-11/+82
The BCM2835 SPI driver currently sets the SPI_CONTROLLER_MUST_TX flag. When performing an RX-only transfer, this flag causes the SPI core to allocate and DMA-map a dummy buffer which is copied to the TX FIFO. The dummy buffer is necessary because the chip is not capable of automatically clocking out null bytes. Avoid the overhead induced by the dummy buffer by preallocating a reusable DMA transaction which fills the TX FIFO by cyclically copying from the zero page. The transaction requires very little CPU time to submit and generates no interrupts while running. Specifics are provided in kerneldoc comments. [Nathan Chancellor contributed a DMA mapping fixup for an early version of this commit, hence his Signed-off-by.] Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Link: https://lore.kernel.org/r/f45920af18dbf06e34129bbc406f53dc9c5d1075.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Speed up TX-only DMA transfers by clearing RX FIFOLukas Wunner1-23/+218
The BCM2835 SPI driver currently sets the SPI_CONTROLLER_MUST_RX flag. When performing a TX-only transfer, this flag causes the SPI core to allocate and DMA-map a dummy buffer into which the RX FIFO contents are copied. The dummy buffer is necessary because the chip is not capable of disabling the receiver or automatically throwing away received data. Not reading the RX FIFO isn't an option either since transmission is halted once it's full. Avoid the overhead induced by the dummy buffer by preallocating a reusable DMA transaction which cyclically clears the RX FIFO. The transaction requires very little CPU time to submit and generates no interrupts while running. Specifics are provided in kerneldoc comments. With a ks8851 Ethernet chip attached to the SPI controller, I am seeing a 30 us reduction in ping time with this commit (1.819 ms vs. 1.849 ms, average of 100,000 packets) as well as a 2% reduction in CPU time (75:08 vs. 76:39 for transmission of 5 GByte over the SPI bus). The commit uses the TX DMA interrupt to signal completion of a transfer. This interrupt is raised once all bytes have been written to the TX FIFO and it is then necessary to busy-wait for the TX FIFO to become empty before the transfer can be finalized. As an alternative approach, I have explored using the SPI controller's DONE interrupt to detect completion. This interrupt is signaled when the TX FIFO becomes empty, avoiding the need to busy-wait. However latency deteriorates compared to the present commit and surprisingly, CPU time is slightly higher as well: It turns out that in 45% of the cases, no busy-waiting is needed at all and in 76% of the cases, less than 10 busy-wait iterations are sufficient for the TX FIFO to drain. This was measured on an RT kernel. On a vanilla kernel, wakeup latency is worse and thus fewer iterations are needed. The measurements were made with an SPI clock of 20 MHz, they may differ slightly for slower or faster clock speeds. Previously we always used the RX DMA interrupt to signal completion of a transfer. Using the TX DMA interrupt now introduces a race condition: TX DMA is always started before RX DMA so that bytes are already clocked out while RX DMA is still being set up. But if a TX-only transfer is very short, then the TX DMA interrupt may occur before RX DMA is set up. If the interrupt happens to occur on the same CPU, setup of RX DMA may even be delayed until after the interrupt was handled. I've solved this by having the TX DMA callback clear the RX FIFO while busy-waiting for the TX FIFO to drain, thus avoiding a dependency on setup of RX DMA. Additionally, I am using a lock-free mechanism with two flags, tx_dma_active and rx_dma_active plus memory barriers to terminate RX DMA either by the TX DMA callback or immediately after setting it up, whichever wins the race. I've explored an alternative approach which temporarily disables the TX DMA callback until RX DMA has been set up (using tasklet_disable(), local_bh_disable() or local_irq_save()), but the performance was minimally worse. [Nathan Chancellor contributed a DMA mapping fixup for an early version of this commit, hence his Signed-off-by.] Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Cc: Robert Jarzmik <robert.jarzmik@free.fr> Link: https://lore.kernel.org/r/874949385f28251e2dcaa9494e39a27b50e9f9e4.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Cache CS register value for ->prepare_message()Lukas Wunner1-20/+26
The BCM2835 SPI driver needs to set up the clock polarity in its ->prepare_message() hook before spi_transfer_one_message() asserts chip select to avoid a gratuitous clock signal edge (cf. commit acace73df2c1 ("spi: bcm2835: set up spi-mode before asserting cs-gpio")). Precalculate the CS register value (which selects the clock polarity) once in ->setup() and use that cached value in ->prepare_message() and ->transfer_one(). This avoids one MMIO read per message and one per transfer, yielding a small latency improvement. Additionally, a forthcoming commit will use the precalculated value to derive the register value for clearing the RX FIFO, which will eliminate the need for an RX dummy buffer when performing TX-only DMA transfers. Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/d17c1d7fcdc97fffa961b8737cfd80eeb14f9416.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: Guarantee cacheline alignment of driver-private dataLukas Wunner1-4/+7
__spi_alloc_controller() uses a single allocation to accommodate struct spi_controller and the driver-private data, but places the latter behind the former. This order does not guarantee cacheline alignment of the driver-private data. (It does guarantee cacheline alignment of struct spi_controller but the structure doesn't make any use of that property.) Round up struct spi_controller to cacheline size. A forthcoming commit leverages this to grant DMA access to driver-private data of the BCM2835 SPI master. An alternative, less economical approach would be to use two allocations. A third approach consists of reversing the order to conserve memory. But Mark Brown is concerned that it may result in a performance penalty on architectures that don't like unaligned accesses. Signed-off-by: Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/01625b9b26b93417fb09d2c15ad02dfe9cdbbbe5.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-11spi: bcm2835: Drop dma_pending flagLukas Wunner1-15/+8
The BCM2835 SPI driver uses a flag to keep track of whether a DMA transfer is in progress. The flag is used to avoid terminating DMA channels multiple times if a transfer finishes orderly while simultaneously the SPI core invokes the ->handle_err() callback because the transfer took too long. However terminating DMA channels multiple times is perfectly fine, so the flag is unnecessary for this particular purpose. The flag is also used to avoid invoking bcm2835_spi_undo_prologue() multiple times under this race condition. However multiple *concurrent* invocations can no longer happen since commit 2527704d8411 ("spi: bcm2835: Synchronize with callback on DMA termination") because the ->handle_err() callback now uses the _sync() variant when terminating DMA channels. The only raison d'être of the flag is therefore that bcm2835_spi_undo_prologue() cannot cope with multiple *sequential* invocations. Achieve that by setting tx_prologue to 0 at the end of the function. Subsequent invocations thus become no-ops. With that, the dma_pending flag becomes unnecessary, so drop it. Tested-by: Nuno Sá <nuno.sa@analog.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/062b03b7f86af77a13ce0ec3b22e0bdbfcfba10d.1568187525.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-10spi: bcm2835: Work around DONE bit erratumLukas Wunner1-2/+12
Commit 3bd7f6589f67 ("spi: bcm2835: Overcome sglist entry length limitation") amended the BCM2835 SPI driver with support for DMA transfers whose buffers are not aligned to 4 bytes and require more than one sglist entry. When testing this feature with upcoming commits to speed up TX-only and RX-only transfers, I noticed that SPI transmission sometimes breaks. A function introduced by the commit, bcm2835_spi_transfer_prologue(), performs one or two PIO transmissions as a prologue to the actual DMA transmission. It turns out that the breakage goes away if the DONE bit in the CS register is set when ending such a PIO transmission. The DONE bit signifies emptiness of the TX FIFO. According to the spec, the bit is of type RO, so writing it should never have any effect. Perhaps the spec is wrong and the bit is actually of type RW1C. E.g. the I2C controller on the BCM2835 does have an RW1C DONE bit which needs to be cleared by the driver. Another, possibly more likely explanation is that it's a hardware erratum since the issue does not occur consistently. Either way, amend bcm2835_spi_transfer_prologue() to always write the DONE bit. Usually a transmission is ended by bcm2835_spi_reset_hw(). If the transmission was successful, the TX FIFO is empty and thus the DONE bit is set when bcm2835_spi_reset_hw() reads the CS register. The bit is then written back to the register, so we happen to do the right thing. However if DONE is not set, e.g. because transmission is aborted with a non-empty TX FIFO, the bit won't be written by bcm2835_spi_reset_hw() and it seems possible that transmission might subsequently break. To be on the safe side, likewise amend bcm2835_spi_reset_hw() to always write the bit. Tested-by: Nuno Sá <nuno.sa@analog.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Stefan Wahren <wahrenst@gmx.net> Acked-by: Martin Sperl <kernel@martin.sperl.org> Link: https://lore.kernel.org/r/edb004dff4af6106f6bfcb89e1a96391e96eb857.1564825752.git.lukas@wunner.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-09spi-gpio: Use PTR_ERR_OR_ZERO() in spi_gpio_request()Markus Elfring1-4/+1
Simplify this function implementation by using a known function. Generated by: scripts/coccinelle/api/ptr_ret.cocci Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/b2dd074a-1693-3aea-42b4-da1f5ec155c4@web.de Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05spi: Use an abbreviated pointer to ctlr->cur_msg in __spi_pump_messagesVladimir Oltean1-11/+12
This helps a bit with line fitting now (the list_first_entry call) as well as during the next patch which needs to iterate through all transfers of ctlr->cur_msg so it timestamps them. Signed-off-by: Vladimir Oltean <olteanv@gmail.com> Link: https://lore.kernel.org/r/20190905010114.26718-2-olteanv@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-05spi: npcm-fiu: remove set but not used variable 'retlen'YueHaibing1-3/+0
drivers/spi/spi-npcm-fiu.c: In function npcm_fiu_read: drivers/spi/spi-npcm-fiu.c:472:9: warning: variable retlen set but not used [-Wunused-but-set-variable] It is never used, so remove it. Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190905072436.23932-1-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: fsl-spi: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-4/+2
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-37-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: zynq-qspi: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-36-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: zynqmp: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-35-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: xlp: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-34-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: uniphier: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-33-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: tegra: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-32-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: sun6i: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-31-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: sun4i: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-30-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: st-ssc4: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-29-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: sirf: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-28-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: sifive: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-27-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: s3c24xx: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-26-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: rb4xx: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-25-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>
2019-09-04spi: spi-qcom-qspi: use devm_platform_ioremap_resource() to simplify codeYueHaibing1-3/+1
Use devm_platform_ioremap_resource() to simplify the code a bit. This is detected by coccinelle. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: YueHaibing <yuehaibing@huawei.com> Link: https://lore.kernel.org/r/20190904135918.25352-24-yuehaibing@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org>