linux.git/drivers, branch v5.13.4

misc: alcor_pci: fix inverted branch condition

2021-07-20T14:00:42+00:00

commit 281e468446994a7672733af2bf941f4110d4a895 upstream.

This patch fixes a trivial mistake that I made in the previous attempt
in fixing the null bridge issue. The branch condition is inverted and we
should call alcor_pci_find_cap_offset() only if bridge is not null.

Reported-by: Colin Ian King 
Fixes: 3ce3e45cc333 ("misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge")
Signed-off-by: Tong Zhang 
Link: https://lore.kernel.org/r/20210522043725.602179-1-ztong0001@gmail.com
Signed-off-by: Greg Kroah-Hartman

scsi: scsi_dh_alua: Fix signedness bug in alua_rtpg()

2021-07-20T14:00:42+00:00

commit 80927822e8b6be46f488524cd7d5fe683de97fc4 upstream.

The "retval" variable needs to be signed for the error handling to work.

Link: https://lore.kernel.org/r/YLjMEAFNxOas1mIp@mwanda
Fixes: 7e26e3ea0287 ("scsi: scsi_dh_alua: Check for negative result value")
Reviewed-by: Martin Wilck 
Signed-off-by: Dan Carpenter 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Greg Kroah-Hartman

cpufreq: CPPC: Fix potential memleak in cppc_cpufreq_cpu_init

2021-07-20T14:00:42+00:00

[ Upstream commit fe2535a44904a77615a3af8e8fd7dafb98fb0e1b ]

It's a classic example of memleak, we allocate something, we fail and
never free the resources.

Make sure we free all resources on policy ->init() failures.

Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list")
Tested-by: Vincent Guittot 
Reviewed-by: Ionela Voinescu 
Tested-by: Qian Cai 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

scsi: be2iscsi: Fix an error handling path in beiscsi_dev_probe()

2021-07-20T14:00:41+00:00

[ Upstream commit 030e4138d11fced3b831c2761e4cecf347bae99c ]

If an error occurs after a pci_enable_pcie_error_reporting() call, it must
be undone by a corresponding pci_disable_pcie_error_reporting() call, as
already done in the remove function.

Link: https://lore.kernel.org/r/77adb02cfea7f1364e5603ecf3930d8597ae356e.1623482155.git.christophe.jaillet@wanadoo.fr
Fixes: 3567f36a09d1 ("[SCSI] be2iscsi: Fix AER handling in driver")
Signed-off-by: Christophe JAILLET 
Signed-off-by: Martin K. Petersen 
Signed-off-by: Sasha Levin

firmware: turris-mox-rwtm: show message about HWRNG registration

2021-07-20T14:00:41+00:00

[ Upstream commit fae20160992269431507708fb74c1fd9f3c309c1 ]

Currently it is hard to determinate if on Armada 3720 device is HWRNG
by running kernel accessible or not. So print information message into
dmesg when HWRNG is available and registration was successful.

Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Pali Rohár 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin

firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng

2021-07-20T14:00:41+00:00

[ Upstream commit 2eab59cf0d2036a5a9e264f719b71c21ccf679c2 ]

When Marvell's rWTM firmware, which does not support the GET_RANDOM
command, is used, kernel prints an error message
  hwrng: no data available
every 10 seconds.

Fail probing of this driver if the rWTM firmware does not support the
GET_RANDOM command.

Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Pali Rohár 
Signed-off-by: Marek Behún 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin

firmware: turris-mox-rwtm: report failures better

2021-07-20T14:00:40+00:00

[ Upstream commit 72f99888944c44de1c899bbe44db1e53bdc9d994 ]

Report a notice level message if a command is not supported by the rWTM
firmware.

This should not be an error, merely a notice, because the firmware can
be used on boards that do not have manufacturing information burned.

Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Marek Behún 
Reviewed-by: Pali Rohár 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin

firmware: turris-mox-rwtm: fix reply status decoding function

2021-07-20T14:00:40+00:00

[ Upstream commit e34e60253d9272311831daed8a2d967cf80ca3dc ]

The status decoding function mox_get_status() currently contains an
incorrect check: if the error status is not MBOX_STS_SUCCESS, it always
returns -EIO, so the comparison to MBOX_STS_FAIL is never executed and
we don't get the actual error code sent by the firmware.

Fix this.

Signed-off-by: Marek Behún 
Reviewed-by: Pali Rohár 
Reviewed-by: Andrew Lunn 
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin

thermal/drivers/rcar_gen3_thermal: Fix coefficient calculations

2021-07-20T14:00:40+00:00

[ Upstream commit 8946187ab57ffd02088e50256c73dd31f49db06d ]

The fixed value of 157 used in the calculations are only correct for
M3-W, on other Gen3 SoC it should be 167. The constant can be derived
correctly from the static TJ_3 constant and the SoC specific TJ_1 value.
Update the calculation be correct on all Gen3 SoCs.

Fixes: 4eb39f79ef44 ("thermal: rcar_gen3_thermal: Update value of Tj_1")
Reported-by: Yoshihiro Shimoda 
Signed-off-by: Niklas Söderlund 
Reviewed-by: Yoshihiro Shimoda 
Reviewed-by: Geert Uytterhoeven 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20210605085211.564909-1-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Sasha Levin

thermal/drivers/sprd: Add missing MODULE_DEVICE_TABLE

2021-07-20T14:00:39+00:00

[ Upstream commit 4d57fd9aeaa013a245bf1fade81e2c30a5efd491 ]

MODULE_DEVICE_TABLE is used to extract the device information out of the
driver and builds a table when being compiled. If using this macro,
kernel can find the driver if available when the device is plugged in,
and then loads that driver and initializes the device.

Fixes: 554fdbaf19b18 ("thermal: sprd: Add Spreadtrum thermal driver support")
Signed-off-by: Chunyan Zhang 
Signed-off-by: Daniel Lezcano 
Link: https://lore.kernel.org/r/20210512093752.243168-1-zhang.lyra@gmail.com
Signed-off-by: Sasha Levin