linux-stable.git/drivers, branch v4.9.248

Input: i8042 - fix error return code in i8042_setup_aux()

2020-12-11T12:38:01+00:00

commit 855b69857830f8d918d715014f05e59a3f7491a0 upstream.

Fix to return a negative error code from the error handling case
instead of 0 in function i8042_setup_aux(), as done elsewhere in this
function.

Fixes: f81134163fc7 ("Input: i8042 - use platform_driver_probe")
Reported-by: Hulk Robot 
Signed-off-by: Luo Meng 
Reviewed-by: Hans de Goede 
Link: https://lore.kernel.org/r/20201123133420.4071187-1-luomeng12@huawei.com
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman

i2c: qup: Fix error return code in qup_i2c_bam_schedule_desc()

2020-12-11T12:38:01+00:00

commit e9acf0298c664f825e6f1158f2a97341bf9e03ca upstream.

Fix to return the error code from qup_i2c_change_state()
instaed of 0 in qup_i2c_bam_schedule_desc().

Fixes: fbf9921f8b35d9b2 ("i2c: qup: Fix error handling")
Reported-by: Hulk Robot 
Signed-off-by: Zhihao Cheng 
Reviewed-by: Bjorn Andersson 
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

spi: bcm2835: Release the DMA channel if probe fails after dma_init

2020-12-11T12:38:01+00:00

[ Upstream commit 666224b43b4bd4612ce3b758c038f9bc5c5e3fcb ]

The DMA channel was not released if either devm_request_irq() or
devm_spi_register_controller() failed.

Signed-off-by: Peter Ujfalusi 
Reviewed-by: Nicolas Saenz Julienne 
Link: https://lore.kernel.org/r/20191212135550.4634-3-peter.ujfalusi@ti.com
Signed-off-by: Mark Brown 
[lukas: backport to 4.19-stable]
Signed-off-by: Lukas Wunner 
Signed-off-by: Greg Kroah-Hartman

spi: bcm2835: Fix use-after-free on unbind

2020-12-11T12:38:01+00:00

[ Upstream commit e1483ac030fb4c57734289742f1c1d38dca61e22 ]

bcm2835_spi_remove() accesses the driver's private data after calling
spi_unregister_controller() even though that function releases the last
reference on the spi_controller and thereby frees the private data.

Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.

Fixes: f8043872e796 ("spi: add driver for BCM2835")
Reported-by: Sascha Hauer 
Reported-by: Florian Fainelli 
Signed-off-by: Lukas Wunner 
Cc:  # v3.10+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc:  # v3.10+
Cc: Vladimir Oltean 
Tested-by: Florian Fainelli 
Acked-by: Florian Fainelli 
Link: https://lore.kernel.org/r/ad66e0a0ad96feb848814842ecf5b6a4539ef35c.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: bcm-qspi: Fix use-after-free on unbind

2020-12-11T12:38:01+00:00

[ Upstream commit 63c5395bb7a9777a33f0e7b5906f2c0170a23692 ]

bcm_qspi_remove() calls spi_unregister_master() even though
bcm_qspi_probe() calls devm_spi_register_master().  The spi_master is
therefore unregistered and freed twice on unbind.

Fix by switching over to the new devm_spi_alloc_master() helper which
keeps the private data accessible until the driver has unbound.

While at it, fix an ordering issue in bcm_qspi_remove() wherein
spi_unregister_master() is called after uninitializing the hardware,
disabling the clock and freeing an IRQ data structure.  The correct
order is to call spi_unregister_master() *before* those teardown steps
because bus accesses may still be ongoing until that function returns.

Fixes: fa236a7ef240 ("spi: bcm-qspi: Add Broadcom MSPI driver")
Signed-off-by: Lukas Wunner 
Cc:  # v4.9+: 5e844cc37a5c: spi: Introduce device-managed SPI controller allocation
Cc:  # v4.9+
Cc: Kamal Dasu 
Acked-by: Florian Fainelli 
Tested-by: Florian Fainelli 
Link: https://lore.kernel.org/r/5e31a9a59fd1c0d0b795b2fe219f25e5ee855f9d.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

spi: Introduce device-managed SPI controller allocation

2020-12-11T12:38:00+00:00

[ Upstream commit 5e844cc37a5cbaa460e68f9a989d321d63088a89 ]

SPI driver probing currently comprises two steps, whereas removal
comprises only one step:

    spi_alloc_master()
    spi_register_master()

    spi_unregister_master()

That's because spi_unregister_master() calls device_unregister()
instead of device_del(), thereby releasing the reference on the
spi_master which was obtained by spi_alloc_master().

An SPI driver's private data is contained in the same memory allocation
as the spi_master struct.  Thus, once spi_unregister_master() has been
called, the private data is inaccessible.  But some drivers need to
access it after spi_unregister_master() to perform further teardown
steps.

Introduce devm_spi_alloc_master(), which releases a reference on the
spi_master struct only after the driver has unbound, thereby keeping the
memory allocation accessible.  Change spi_unregister_master() to not
release a reference if the spi_master was allocated by the new devm
function.

The present commit is small enough to be backportable to stable.
It allows fixing drivers which use the private data in their ->remove()
hook after it's been freed.  It also allows fixing drivers which neglect
to release a reference on the spi_master in the probe error path.

Long-term, most SPI drivers shall be moved over to the devm function
introduced herein.  The few that can't shall be changed in a treewide
commit to explicitly release the last reference on the master.
That commit shall amend spi_unregister_master() to no longer release
a reference, thereby completing the migration.

As a result, the behaviour will be less surprising and more consistent
with subsystems such as IIO, which also includes the private data in the
allocation of the generic iio_dev struct, but calls device_del() in
iio_device_unregister().

Signed-off-by: Lukas Wunner 
Link: https://lore.kernel.org/r/272bae2ef08abd21388c98e23729886663d19192.1605121038.git.lukas@wunner.de
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman

iommu/amd: Set DTE[IntTabLen] to represent 512 IRTEs

2020-12-11T12:38:00+00:00

commit 4165bf015ba9454f45beaad621d16c516d5c5afe upstream.

According to the AMD IOMMU spec, the commit 73db2fc595f3
("iommu/amd: Increase interrupt remapping table limit to 512 entries")
also requires the interrupt table length (IntTabLen) to be set to 9
(power of 2) in the device table mapping entry (DTE).

Fixes: 73db2fc595f3 ("iommu/amd: Increase interrupt remapping table limit to 512 entries")
Reported-by: Jerry Snitselaar 
Signed-off-by: Suravee Suthikulpanit 
Reviewed-by: Jerry Snitselaar 
Link: https://lore.kernel.org/r/20201207091920.3052-1-suravee.suthikulpanit@amd.com
Signed-off-by: Will Deacon 
Signed-off-by: Greg Kroah-Hartman

i2c: imx: Check for I2SR_IAL after every byte

2020-12-11T12:38:00+00:00

commit 1de67a3dee7a279ebe4d892b359fe3696938ec15 upstream.

Arbitration Lost (IAL) can happen after every single byte transfer. If
arbitration is lost, the I2C hardware will autonomously switch from
master mode to slave. If a transfer is not aborted in this state,
consecutive transfers will not be executed by the hardware and will
timeout.

Signed-off-by: Christian Eggers 
Tested (not extensively) on Vybrid VF500 (Toradex VF50):
Tested-by: Krzysztof Kozlowski 
Acked-by: Oleksij Rempel 
Cc: stable@vger.kernel.org
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

i2c: imx: Fix reset of I2SR_IAL flag

2020-12-11T12:38:00+00:00

commit 384a9565f70a876c2e78e58c5ca0bbf0547e4f6d upstream.

According to the "VFxxx Controller Reference Manual" (and the comment
block starting at line 97), Vybrid requires writing a one for clearing
an interrupt flag. Syncing the method for clearing I2SR_IIF in
i2c_imx_isr().

Signed-off-by: Christian Eggers 
Fixes: 4b775022f6fd ("i2c: imx: add struct to hold more configurable quirks")
Reviewed-by: Uwe Kleine-König 
Acked-by: Oleksij Rempel 
Cc: stable@vger.kernel.org
Signed-off-by: Wolfram Sang 
Signed-off-by: Greg Kroah-Hartman

tty: Fix ->session locking

2020-12-11T12:38:00+00:00

commit c8bcd9c5be24fb9e6132e97da5a35e55a83e36b9 upstream.

Currently, locking of ->session is very inconsistent; most places
protect it using the legacy tty mutex, but disassociate_ctty(),
__do_SAK(), tiocspgrp() and tiocgsid() don't.
Two of the writers hold the ctrl_lock (because they already need it for
->pgrp), but __proc_set_tty() doesn't do that yet.

On a PREEMPT=y system, an unprivileged user can theoretically abuse
this broken locking to read 4 bytes of freed memory via TIOCGSID if
tiocgsid() is preempted long enough at the right point. (Other things
might also go wrong, especially if root-only ioctls are involved; I'm
not sure about that.)

Change the locking on ->session such that:

 - tty_lock() is held by all writers: By making disassociate_ctty()
   hold it. This should be fine because the same lock can already be
   taken through the call to tty_vhangup_session().
   The tricky part is that we need to shorten the area covered by
   siglock to be able to take tty_lock() without ugly retry logic; as
   far as I can tell, this should be fine, since nothing in the
   signal_struct is touched in the `if (tty)` branch.
 - ctrl_lock is held by all writers: By changing __proc_set_tty() to
   hold the lock a little longer.
 - All readers that aren't holding tty_lock() hold ctrl_lock: By
   adding locking to tiocgsid() and __do_SAK(), and expanding the area
   covered by ctrl_lock in tiocspgrp().

Cc: stable@kernel.org
Signed-off-by: Jann Horn 
Reviewed-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman