<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/spi, branch v4.19.201</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>spi: spi-fsl-dspi: Fix a resource leak in an error handling path</title>
<updated>2021-07-28T09:13:52+00:00</updated>
<author>
<name>Christophe JAILLET</name>
<email>christophe.jaillet@wanadoo.fr</email>
</author>
<published>2021-05-09T19:12:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00450ed03a17143e2433b461a656ef9cd17c2f1d'/>
<id>00450ed03a17143e2433b461a656ef9cd17c2f1d</id>
<content type='text'>
commit 680ec0549a055eb464dce6ffb4bfb736ef87236e upstream

'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
error handling path of the probe function, as already done in the remove
function

Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Link: https://lore.kernel.org/r/d51caaac747277a1099ba8dea07acd85435b857e.1620587472.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 680ec0549a055eb464dce6ffb4bfb736ef87236e upstream

'dspi_request_dma()' should be undone by a 'dspi_release_dma()' call in the
error handling path of the probe function, as already done in the remove
function

Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid")
Signed-off-by: Christophe JAILLET &lt;christophe.jaillet@wanadoo.fr&gt;
Reviewed-by: Vladimir Oltean &lt;olteanv@gmail.com&gt;
Link: https://lore.kernel.org/r/d51caaac747277a1099ba8dea07acd85435b857e.1620587472.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[sudip: adjust context]
Signed-off-by: Sudip Mukherjee &lt;sudipm.mukherjee@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: cadence: Correct initialisation of runtime PM again</title>
<updated>2021-07-28T09:13:48+00:00</updated>
<author>
<name>Marek Vasut</name>
<email>marex@denx.de</email>
</author>
<published>2021-07-16T18:21:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=5df32cc4db806fda51f00bf6b4f7163857060bdf'/>
<id>5df32cc4db806fda51f00bf6b4f7163857060bdf</id>
<content type='text'>
[ Upstream commit 56912da7a68c8356df6a6740476237441b0b792a ]

The original implementation of RPM handling in probe() was mostly
correct, except it failed to call pm_runtime_get_*() to activate the
hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
initialisation of runtime PM"), breaks the implementation further,
to the point where the system using this hard IP on ZynqMP hangs on
boot, because it accesses hardware which is gated off.

Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
PM") and instead add missing pm_runtime_get_noresume() and move the
RPM disabling all the way to the end of probe(). That makes ZynqMP
not hang on boot yet again.

Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 56912da7a68c8356df6a6740476237441b0b792a ]

The original implementation of RPM handling in probe() was mostly
correct, except it failed to call pm_runtime_get_*() to activate the
hardware. The subsequent fix, 734882a8bf98 ("spi: cadence: Correct
initialisation of runtime PM"), breaks the implementation further,
to the point where the system using this hard IP on ZynqMP hangs on
boot, because it accesses hardware which is gated off.

Undo 734882a8bf98 ("spi: cadence: Correct initialisation of runtime
PM") and instead add missing pm_runtime_get_noresume() and move the
RPM disabling all the way to the end of probe(). That makes ZynqMP
not hang on boot yet again.

Fixes: 734882a8bf98 ("spi: cadence: Correct initialisation of runtime PM")
Signed-off-by: Marek Vasut &lt;marex@denx.de&gt;
Cc: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Cc: Mark Brown &lt;broonie@kernel.org&gt;
Link: https://lore.kernel.org/r/20210716182133.218640-1-marex@denx.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: mediatek: fix fifo rx mode</title>
<updated>2021-07-28T09:13:47+00:00</updated>
<author>
<name>Peter Hess</name>
<email>peter.hess@ph-home.de</email>
</author>
<published>2021-07-06T12:16:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd0447f72de0963129612bf18202204d5b25e133'/>
<id>bd0447f72de0963129612bf18202204d5b25e133</id>
<content type='text'>
[ Upstream commit 3a70dd2d050331ee4cf5ad9d5c0a32d83ead9a43 ]

In FIFO mode were two problems:
- RX mode was never handled and
- in this case the tx_buf pointer was NULL and caused an exception

fix this by handling RX mode in mtk_spi_fifo_transfer

Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173")
Signed-off-by: Peter Hess &lt;peter.hess@ph-home.de&gt;
Signed-off-by: Frank Wunderlich &lt;frank-w@public-files.de&gt;
Link: https://lore.kernel.org/r/20210706121609.680534-1-linux@fw-web.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 3a70dd2d050331ee4cf5ad9d5c0a32d83ead9a43 ]

In FIFO mode were two problems:
- RX mode was never handled and
- in this case the tx_buf pointer was NULL and caused an exception

fix this by handling RX mode in mtk_spi_fifo_transfer

Fixes: a568231f4632 ("spi: mediatek: Add spi bus for Mediatek MT8173")
Signed-off-by: Peter Hess &lt;peter.hess@ph-home.de&gt;
Signed-off-by: Frank Wunderlich &lt;frank-w@public-files.de&gt;
Link: https://lore.kernel.org/r/20210706121609.680534-1-linux@fw-web.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-sun6i: Fix chipselect/clock bug</title>
<updated>2021-07-20T14:15:48+00:00</updated>
<author>
<name>Mirko Vogt</name>
<email>mirko-dev|linux@nanl.de</email>
</author>
<published>2021-06-14T14:45:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ed556eef5fedd69219dfa8e0e3864347eff8e76e'/>
<id>ed556eef5fedd69219dfa8e0e3864347eff8e76e</id>
<content type='text'>
[ Upstream commit 0d7993b234c9fad8cb6bec6adfaa74694ba85ecb ]

The current sun6i SPI implementation initializes the transfer too early,
resulting in SCK going high before the transfer. When using an additional
(gpio) chipselect with sun6i, the chipselect is asserted at a time when
clock is high, making the SPI transfer fail.

This is due to SUN6I_GBL_CTL_BUS_ENABLE being written into
SUN6I_GBL_CTL_REG at an early stage. Moving that to the transfer
function, hence, right before the transfer starts, mitigates that
problem.

Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Mirko Vogt &lt;mirko-dev|linux@nanl.de&gt;
Signed-off-by: Ralf Schlatterbeck &lt;rsc@runtux.com&gt;
Link: https://lore.kernel.org/r/20210614144507.y3udezjfbko7eavv@runtux.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0d7993b234c9fad8cb6bec6adfaa74694ba85ecb ]

The current sun6i SPI implementation initializes the transfer too early,
resulting in SCK going high before the transfer. When using an additional
(gpio) chipselect with sun6i, the chipselect is asserted at a time when
clock is high, making the SPI transfer fail.

This is due to SUN6I_GBL_CTL_BUS_ENABLE being written into
SUN6I_GBL_CTL_REG at an early stage. Moving that to the transfer
function, hence, right before the transfer starts, mitigates that
problem.

Fixes: 3558fe900e8af (spi: sunxi: Add Allwinner A31 SPI controller driver)
Signed-off-by: Mirko Vogt &lt;mirko-dev|linux@nanl.de&gt;
Signed-off-by: Ralf Schlatterbeck &lt;rsc@runtux.com&gt;
Link: https://lore.kernel.org/r/20210614144507.y3udezjfbko7eavv@runtux.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: omap-100k: Fix the length judgment problem</title>
<updated>2021-07-20T14:15:43+00:00</updated>
<author>
<name>Tian Tao</name>
<email>tiantao6@hisilicon.com</email>
</author>
<published>2021-04-29T11:20:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a741b1bd7068ed8a750f9240d4e17c93f1b22a25'/>
<id>a741b1bd7068ed8a750f9240d4e17c93f1b22a25</id>
<content type='text'>
[ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ]

word_len should be checked in the omap1_spi100k_setup_transfer
function to see if it exceeds 32.

Signed-off-by: Tian Tao &lt;tiantao6@hisilicon.com&gt;
Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit e7a1a3abea373e41ba7dfe0fbc93cb79b6a3a529 ]

word_len should be checked in the omap1_spi100k_setup_transfer
function to see if it exceeds 32.

Signed-off-by: Tian Tao &lt;tiantao6@hisilicon.com&gt;
Link: https://lore.kernel.org/r/1619695248-39045-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-topcliff-pch: Fix potential double free in pch_spi_process_messages()</title>
<updated>2021-07-20T14:15:43+00:00</updated>
<author>
<name>Jay Fang</name>
<email>f.fangjian@huawei.com</email>
</author>
<published>2021-05-06T07:08:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=880ec021ed3b665014b74784311cb8b5bc736854'/>
<id>880ec021ed3b665014b74784311cb8b5bc736854</id>
<content type='text'>
[ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ]

pch_spi_set_tx() frees data-&gt;pkt_tx_buff on failure of kzalloc() for
data-&gt;pkt_rx_buff, but its caller, pch_spi_process_messages(), will
free data-&gt;pkt_tx_buff again. Set data-&gt;pkt_tx_buff to NULL after
kfree() to avoid double free.

Signed-off-by: Jay Fang &lt;f.fangjian@huawei.com&gt;
Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 026a1dc1af52742c5897e64a3431445371a71871 ]

pch_spi_set_tx() frees data-&gt;pkt_tx_buff on failure of kzalloc() for
data-&gt;pkt_rx_buff, but its caller, pch_spi_process_messages(), will
free data-&gt;pkt_tx_buff again. Set data-&gt;pkt_tx_buff to NULL after
kfree() to avoid double free.

Signed-off-by: Jay Fang &lt;f.fangjian@huawei.com&gt;
Link: https://lore.kernel.org/r/1620284888-65215-1-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: spi-loopback-test: Fix 'tx_buf' might be 'rx_buf'</title>
<updated>2021-07-20T14:15:43+00:00</updated>
<author>
<name>Jay Fang</name>
<email>f.fangjian@huawei.com</email>
</author>
<published>2021-05-10T06:58:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ffd424a94a44418714dfedeb5fc091e63e4ae1ad'/>
<id>ffd424a94a44418714dfedeb5fc091e63e4ae1ad</id>
<content type='text'>
[ Upstream commit 9e37a3ab0627011fb63875e9a93094b6fc8ddf48 ]

In function 'spi_test_run_iter': Value 'tx_buf' might be 'rx_buf'.

Signed-off-by: Jay Fang &lt;f.fangjian@huawei.com&gt;
Link: https://lore.kernel.org/r/1620629903-15493-5-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 9e37a3ab0627011fb63875e9a93094b6fc8ddf48 ]

In function 'spi_test_run_iter': Value 'tx_buf' might be 'rx_buf'.

Signed-off-by: Jay Fang &lt;f.fangjian@huawei.com&gt;
Link: https://lore.kernel.org/r/1620629903-15493-5-git-send-email-f.fangjian@huawei.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: Make of_register_spi_device also set the fwnode</title>
<updated>2021-07-20T14:15:43+00:00</updated>
<author>
<name>Charles Keepax</name>
<email>ckeepax@opensource.cirrus.com</email>
</author>
<published>2021-04-21T10:14:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=878c5d126b8e2c4b7b3b1a69288c0866d38774a8'/>
<id>878c5d126b8e2c4b7b3b1a69288c0866d38774a8</id>
<content type='text'>
[ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ]

Currently, the SPI core doesn't set the struct device fwnode pointer
when it creates a new SPI device. This means when the device is
registered the fwnode is NULL and the check in device_add which sets
the fwnode-&gt;dev pointer is skipped. This wasn't previously an issue,
however these two patches:

commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
fw_devlink=on by default")
commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the
primary device")

Added some code to the GPIO core which relies on using that
fwnode-&gt;dev pointer to determine if a driver is bound to the fwnode
and if not bind a stub GPIO driver. This means the GPIO providers
behind SPI will get both the expected driver and this stub driver
causing the stub driver to fail if it attempts to request any pin
configuration. For example on my system:

madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3
madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22
madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1  on device madera-pinctrl
gpio_stub_drv gpiochip3: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip3 failed with error -22

The firmware node on the device created by the GPIO framework is set
through the of_node pointer hence things generally actually work,
however that fwnode-&gt;dev is never set, as the check was skipped at
device_add time. This fix appears to match how the I2C subsystem
handles the same situation.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 0e793ba77c18382f08e440260fe72bc6fce2a3cb ]

Currently, the SPI core doesn't set the struct device fwnode pointer
when it creates a new SPI device. This means when the device is
registered the fwnode is NULL and the check in device_add which sets
the fwnode-&gt;dev pointer is skipped. This wasn't previously an issue,
however these two patches:

commit 4731210c09f5 ("gpiolib: Bind gpio_device to a driver to enable
fw_devlink=on by default")
commit ced2af419528 ("gpiolib: Don't probe gpio_device if it's not the
primary device")

Added some code to the GPIO core which relies on using that
fwnode-&gt;dev pointer to determine if a driver is bound to the fwnode
and if not bind a stub GPIO driver. This means the GPIO providers
behind SPI will get both the expected driver and this stub driver
causing the stub driver to fail if it attempts to request any pin
configuration. For example on my system:

madera-pinctrl madera-pinctrl: pin gpio5 already requested by madera-pinctrl; cannot claim for gpiochip3
madera-pinctrl madera-pinctrl: pin-4 (gpiochip3) status -22
madera-pinctrl madera-pinctrl: could not request pin 4 (gpio5) from group aif1  on device madera-pinctrl
gpio_stub_drv gpiochip3: Error applying setting, reverse things back
gpio_stub_drv: probe of gpiochip3 failed with error -22

The firmware node on the device created by the GPIO framework is set
through the of_node pointer hence things generally actually work,
however that fwnode-&gt;dev is never set, as the check was skipped at
device_add time. This fix appears to match how the I2C subsystem
handles the same situation.

Signed-off-by: Charles Keepax &lt;ckeepax@opensource.cirrus.com&gt;
Link: https://lore.kernel.org/r/20210421101402.8468-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: gpio: Don't leak SPI master in probe error path</title>
<updated>2021-06-03T06:38:07+00:00</updated>
<author>
<name>Lukas Wunner</name>
<email>lukas@wunner.de</email>
</author>
<published>2020-12-07T08:17:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=992957c2dbbe1bae4915d6fc938a82323405c944'/>
<id>992957c2dbbe1bae4915d6fc938a82323405c944</id>
<content type='text'>
commit 7174dc655ef0578877b0b4598e69619d2be28b4d upstream.

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 &lt;lukas@wunner.de&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 8b797490b4db: spi: gpio: Make sure spi_master_put() is called in every error path
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 45beec351998: spi: bitbang: Introduce spi_bitbang_init()
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 79567c1a321e: spi: gpio: Use devm_spi_register_master()
Cc: &lt;stable@vger.kernel.org&gt; # v5.4-: d3b0ffa1d75d: spi: gpio: prevent memory leak in spi_gpio_probe
Cc: &lt;stable@vger.kernel.org&gt; # v4.17+
Cc: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Cc: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[lukas: backport to v4.19.192]
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7174dc655ef0578877b0b4598e69619d2be28b4d upstream.

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 &lt;lukas@wunner.de&gt;
Reviewed-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.17+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 8b797490b4db: spi: gpio: Make sure spi_master_put() is called in every error path
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 45beec351998: spi: bitbang: Introduce spi_bitbang_init()
Cc: &lt;stable@vger.kernel.org&gt; # v5.1-: 79567c1a321e: spi: gpio: Use devm_spi_register_master()
Cc: &lt;stable@vger.kernel.org&gt; # v5.4-: d3b0ffa1d75d: spi: gpio: prevent memory leak in spi_gpio_probe
Cc: &lt;stable@vger.kernel.org&gt; # v4.17+
Cc: Navid Emamdoost &lt;navid.emamdoost@gmail.com&gt;
Cc: Andrey Smirnov &lt;andrew.smirnov@gmail.com&gt;
Link: https://lore.kernel.org/r/86eaed27431c3d709e3748eb76ceecbfc790dd37.1607286887.git.lukas@wunner.de
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
[lukas: backport to v4.19.192]
Signed-off-by: Lukas Wunner &lt;lukas@wunner.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>spi: Fix use-after-free with devm_spi_alloc_*</title>
<updated>2021-05-22T08:59:30+00:00</updated>
<author>
<name>William A. Kennington III</name>
<email>wak@google.com</email>
</author>
<published>2021-04-07T09:55:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=28a5529068c51cdf0295ab1e11a99a3a909a03e4'/>
<id>28a5529068c51cdf0295ab1e11a99a3a909a03e4</id>
<content type='text'>
[ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ]

We can't rely on the contents of the devres list during
spi_unregister_controller(), as the list is already torn down at the
time we perform devres_find() for devm_spi_release_controller. This
causes devices registered with devm_spi_alloc_{master,slave}() to be
mistakenly identified as legacy, non-devm managed devices and have their
reference counters decremented below 0.

------------[ cut here ]------------
WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174
[&lt;b0396f04&gt;] (refcount_warn_saturate) from [&lt;b03c56a4&gt;] (kobject_put+0x90/0x98)
[&lt;b03c5614&gt;] (kobject_put) from [&lt;b0447b4c&gt;] (put_device+0x20/0x24)
 r4:b6700140
[&lt;b0447b2c&gt;] (put_device) from [&lt;b07515e8&gt;] (devm_spi_release_controller+0x3c/0x40)
[&lt;b07515ac&gt;] (devm_spi_release_controller) from [&lt;b045343c&gt;] (release_nodes+0x84/0xc4)
 r5:b6700180 r4:b6700100
[&lt;b04533b8&gt;] (release_nodes) from [&lt;b0454160&gt;] (devres_release_all+0x5c/0x60)
 r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10
[&lt;b0454104&gt;] (devres_release_all) from [&lt;b044e41c&gt;] (__device_release_driver+0x144/0x1ec)
 r5:b117ad94 r4:b163dc10
[&lt;b044e2d8&gt;] (__device_release_driver) from [&lt;b044f70c&gt;] (device_driver_detach+0x84/0xa0)
 r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10
[&lt;b044f688&gt;] (device_driver_detach) from [&lt;b044d274&gt;] (unbind_store+0xe4/0xf8)

Instead, determine the devm allocation state as a flag on the
controller which is guaranteed to be stable during cleanup.

Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation")
Signed-off-by: William A. Kennington III &lt;wak@google.com&gt;
Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 794aaf01444d4e765e2b067cba01cc69c1c68ed9 ]

We can't rely on the contents of the devres list during
spi_unregister_controller(), as the list is already torn down at the
time we perform devres_find() for devm_spi_release_controller. This
causes devices registered with devm_spi_alloc_{master,slave}() to be
mistakenly identified as legacy, non-devm managed devices and have their
reference counters decremented below 0.

------------[ cut here ]------------
WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174
[&lt;b0396f04&gt;] (refcount_warn_saturate) from [&lt;b03c56a4&gt;] (kobject_put+0x90/0x98)
[&lt;b03c5614&gt;] (kobject_put) from [&lt;b0447b4c&gt;] (put_device+0x20/0x24)
 r4:b6700140
[&lt;b0447b2c&gt;] (put_device) from [&lt;b07515e8&gt;] (devm_spi_release_controller+0x3c/0x40)
[&lt;b07515ac&gt;] (devm_spi_release_controller) from [&lt;b045343c&gt;] (release_nodes+0x84/0xc4)
 r5:b6700180 r4:b6700100
[&lt;b04533b8&gt;] (release_nodes) from [&lt;b0454160&gt;] (devres_release_all+0x5c/0x60)
 r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10
[&lt;b0454104&gt;] (devres_release_all) from [&lt;b044e41c&gt;] (__device_release_driver+0x144/0x1ec)
 r5:b117ad94 r4:b163dc10
[&lt;b044e2d8&gt;] (__device_release_driver) from [&lt;b044f70c&gt;] (device_driver_detach+0x84/0xa0)
 r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10
[&lt;b044f688&gt;] (device_driver_detach) from [&lt;b044d274&gt;] (unbind_store+0xe4/0xf8)

Instead, determine the devm allocation state as a flag on the
controller which is guaranteed to be stable during cleanup.

Fixes: 5e844cc37a5c ("spi: Introduce device-managed SPI controller allocation")
Signed-off-by: William A. Kennington III &lt;wak@google.com&gt;
Link: https://lore.kernel.org/r/20210407095527.2771582-1-wak@google.com
Signed-off-by: Mark Brown &lt;broonie@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
