linux-stable.git/drivers/spi, branch v5.4.11 Linux kernel stable tree spi: nxp-fspi: Ensure width is respected in spi-mem operations 2020-01-12T11:21:34+00:00 Michael Walle michael@walle.cc 2019-12-11T19:57:30+00:00 9e713aa4c15c9cbb39aa4994cb61ef5584ad97e8 [ Upstream commit 007773e16a6f3f49d1439554078c3ba8af131998 ] Make use of a core helper to ensure the desired width is respected when calling spi-mem operators. Otherwise only the SPI controller will be matched with the flash chip, which might lead to wrong widths. Also consider the width specified by the user in the device tree. Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Signed-off-by: Michael Walle <michael@walle.cc> Link: https://lore.kernel.org/r/20191211195730.26794-1-michael@walle.cc Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 007773e16a6f3f49d1439554078c3ba8af131998 ]

Make use of a core helper to ensure the desired width is respected
when calling spi-mem operators.

Otherwise only the SPI controller will be matched with the flash chip,
which might lead to wrong widths. Also consider the width specified by
the user in the device tree.

Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller")
Signed-off-by: Michael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20191211195730.26794-1-michael@walle.cc
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: spi-ti-qspi: Fix a bug when accessing non default CS 2020-01-12T11:21:25+00:00 Vignesh Raghavendra vigneshr@ti.com 2019-12-11T15:52:16+00:00 e5b874829a9e9f229c962572675d259a431a5757 [ Upstream commit c52c91bb9aa6bd8c38dbf9776158e33038aedd43 ] When switching ChipSelect from default CS0 to any other CS, driver fails to update the bits in system control module register that control which CS is mapped for MMIO access. This causes reads to fail when driver tries to access QSPI flash on CS1/2/3. Fix this by updating appropriate bits whenever active CS changes. Reported-by: Andreas Dannenberg <dannenberg@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Link: https://lore.kernel.org/r/20191211155216.30212-1-vigneshr@ti.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c52c91bb9aa6bd8c38dbf9776158e33038aedd43 ]

When switching ChipSelect from default CS0 to any other CS, driver fails
to update the bits in system control module register that control which
CS is mapped for MMIO access. This causes reads to fail when driver
tries to access QSPI flash on CS1/2/3.

Fix this by updating appropriate bits whenever active CS changes.

Reported-by: Andreas Dannenberg <dannenberg@ti.com>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Link: https://lore.kernel.org/r/20191211155216.30212-1-vigneshr@ti.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: spi-cavium-thunderx: Add missing pci_release_regions() 2020-01-12T11:21:20+00:00 Chuhong Yuan hslester96@gmail.com 2019-12-06T07:55:00+00:00 ec32cd3673e777ab470a84d35292cdf552d30917 [ Upstream commit a841e2853e1afecc2ee692b8cc5bff606bc84e4c ] The driver forgets to call pci_release_regions() 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/20191206075500.18525-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a841e2853e1afecc2ee692b8cc5bff606bc84e4c ]

The driver forgets to call pci_release_regions() 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/20191206075500.18525-1-hslester96@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: fsl: Handle the single hardwired chipselect case 2020-01-12T11:21:13+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-28T08:37:18+00:00 5a2d941e7a737999952e5bd37f99e34988fd22e5 [ Upstream commit 7251953d784baf7e5416afabe030a0e81de1a938 ] The Freescale MPC8xxx had a special quirk for handling a single hardwired chipselect, the case when we're using neither GPIO nor native chip select: when inspecting the device tree and finding zero "cs-gpios" on the device node the code would assume we have a single hardwired chipselect that leaves the device always selected. This quirk is not handled by the new core code, so we need to check the "cs-gpios" explicitly in the driver and set pdata->max_chipselect = 1 which will later fall through to the SPI master ->num_chipselect. Make sure not to assign the chip select handler in this case: there is no handling needed since the chip is always selected, and this is what the old code did as well. Cc: Christophe Leroy <christophe.leroy@c-s.fr> Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> (No tested the Link: https://lore.kernel.org/r/20191128083718.39177-3-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7251953d784baf7e5416afabe030a0e81de1a938 ]

The Freescale MPC8xxx had a special quirk for handling a
single hardwired chipselect, the case when we're using neither
GPIO nor native chip select: when inspecting the device tree
and finding zero "cs-gpios" on the device node the code would
assume we have a single hardwired chipselect that leaves the
device always selected.

This quirk is not handled by the new core code, so we need
to check the "cs-gpios" explicitly in the driver and set
pdata->max_chipselect = 1 which will later fall through to
the SPI master ->num_chipselect.

Make sure not to assign the chip select handler in this
case: there is no handling needed since the chip is always
selected, and this is what the old code did as well.

Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> (No tested the
Link: https://lore.kernel.org/r/20191128083718.39177-3-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: fsl: Fix GPIO descriptor support 2020-01-12T11:21:12+00:00 Linus Walleij linus.walleij@linaro.org 2019-11-28T08:37:16+00:00 9d646e70f6deb5ca2b1a3e0c530205c076fd2a85 [ Upstream commit f106904968e2a075e64653b9b79dda9f0f070ab5 ] This makes the driver actually support looking up GPIO descriptor. A coding mistake in the initial descriptor support patch was that it was failing to turn on the very feature it was implementing. Mea culpa. Cc: Christophe Leroy <christophe.leroy@c-s.fr> Reported-by: Christophe Leroy <christophe.leroy@c-s.fr> Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Tested-by: Christophe Leroy <christophe.leroy@c-s.fr> Link: https://lore.kernel.org/r/20191128083718.39177-1-linus.walleij@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f106904968e2a075e64653b9b79dda9f0f070ab5 ]

This makes the driver actually support looking up GPIO
descriptor. A coding mistake in the initial descriptor
support patch was that it was failing to turn on the very
feature it was implementing. Mea culpa.

Cc: Christophe Leroy <christophe.leroy@c-s.fr>
Reported-by: Christophe Leroy <christophe.leroy@c-s.fr>
Fixes: 0f0581b24bd0 ("spi: fsl: Convert to use CS GPIO descriptors")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
Link: https://lore.kernel.org/r/20191128083718.39177-1-linus.walleij@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: pxa2xx: Add support for Intel Jasper Lake 2020-01-12T11:21:11+00:00 Jarkko Nikula jarkko.nikula@linux.intel.com 2019-11-25T12:51:59+00:00 10597f80ebddae8d2089e6abad54f8155106b5f4 [ Upstream commit 9c7315c9fca5de203538163cf42699bb10328902 ] LPSS SPI on Intel Jasper Lake is compatible with Intel Ice Lake which follows Intel Cannon Lake. Add PCI IDs of Jasper Lake. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20191125125159.15404-1-jarkko.nikula@linux.intel.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 9c7315c9fca5de203538163cf42699bb10328902 ]

LPSS SPI on Intel Jasper Lake is compatible with Intel Ice Lake which
follows Intel Cannon Lake. Add PCI IDs of Jasper Lake.

Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Link: https://lore.kernel.org/r/20191125125159.15404-1-jarkko.nikula@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
spi: uniphier: Fix FIFO threshold 2020-01-09T09:20:04+00:00 Kunihiko Hayashi hayashi.kunihiko@socionext.com 2019-12-24T00:58:23+00:00 d6eeb06587f4053fd586969499af90274f16dabf 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> 
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>
spi: spi-fsl-dspi: Fix 16-bit word order in 32-bit XSPI mode 2020-01-09T09:20:01+00:00 Vladimir Oltean olteanv@gmail.com 2019-12-28T13:55:36+00:00 accc08f40655159c0906c724d80d42099bec4eef 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> 
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>
spi: fsl: use platform_get_irq() instead of of_irq_to_resource() 2019-12-31T15:46:06+00:00 Christophe Leroy christophe.leroy@c-s.fr 2019-12-12T17:47:24+00:00 2ff988de621ac896d5dd9a0139b0da3027891249 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> 
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>
spi: fsl: don't map irq during probe 2019-12-31T15:46:06+00:00 Christophe Leroy christophe.leroy@c-s.fr 2019-12-09T15:27:27+00:00 dac29ae0df4c53e18a61898014e6a1ec553fc13b 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> 
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>