linux-stable.git/drivers/firmware, branch v5.4.161

firmware/psci: fix application of sizeof to pointer

2021-11-17T08:48:17+00:00

commit 2ac5fb35cd520ab1851c9a4816c523b65276052f upstream.

sizeof when applied to a pointer typed expression gives the size of
the pointer.

./drivers/firmware/psci/psci_checker.c:158:41-47: ERROR application of sizeof to pointer

This issue was detected with the help of Coccinelle.

Fixes: 7401056de5f8 ("drivers/firmware: psci_checker: stash and use topology_core_cpumask for hotplug tests")
Cc: stable@vger.kernel.org
Reported-by: Zeal Robot 
Acked-by: Mark Rutland 
Reviewed-by: Gustavo A. R. Silva 
Signed-off-by: jing yangyang 
Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Greg Kroah-Hartman

efi: Change down_interruptible() in virt_efi_reset_system() to down_trylock()

2021-10-20T09:40:14+00:00

commit 38fa3206bf441911258e5001ac8b6738693f8d82 upstream.

While reboot the system by sysrq, the following bug will be occur.

BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:90
in_atomic(): 0, irqs_disabled(): 128, non_block: 0, pid: 10052, name: rc.shutdown
CPU: 3 PID: 10052 Comm: rc.shutdown Tainted: G        W O      5.10.0 #1
Call trace:
 dump_backtrace+0x0/0x1c8
 show_stack+0x18/0x28
 dump_stack+0xd0/0x110
 ___might_sleep+0x14c/0x160
 __might_sleep+0x74/0x88
 down_interruptible+0x40/0x118
 virt_efi_reset_system+0x3c/0xd0
 efi_reboot+0xd4/0x11c
 machine_restart+0x60/0x9c
 emergency_restart+0x1c/0x2c
 sysrq_handle_reboot+0x1c/0x2c
 __handle_sysrq+0xd0/0x194
 write_sysrq_trigger+0xbc/0xe4
 proc_reg_write+0xd4/0xf0
 vfs_write+0xa8/0x148
 ksys_write+0x6c/0xd8
 __arm64_sys_write+0x18/0x28
 el0_svc_common.constprop.3+0xe4/0x16c
 do_el0_svc+0x1c/0x2c
 el0_svc+0x20/0x30
 el0_sync_handler+0x80/0x17c
 el0_sync+0x158/0x180

The reason for this problem is that irq has been disabled in
machine_restart() and then it calls down_interruptible() in
virt_efi_reset_system(), which would occur sleep in irq context,
it is dangerous! Commit 99409b935c9a("locking/semaphore: Add
might_sleep() to down_*() family") add might_sleep() in
down_interruptible(), so the bug info is here. down_trylock()
can solve this problem, cause there is no might_sleep.

--------

Cc: 
Signed-off-by: Zhang Jianhua 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

efi/cper: use stack buffer for error record decoding

2021-10-20T09:40:14+00:00

commit b3a72ca80351917cc23f9e24c35f3c3979d3c121 upstream.

Joe reports that using a statically allocated buffer for converting CPER
error records into human readable text is probably a bad idea. Even
though we are not aware of any actual issues, a stack buffer is clearly
a better choice here anyway, so let's move the buffer into the stack
frames of the two functions that refer to it.

Cc: 
Reported-by: Joe Perches 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Add delayed response status check

2021-08-08T07:04:08+00:00

commit f1748b1ee1fa0fd1a074504045b530b62f949188 upstream.

A successfully received delayed response could anyway report a failure at
the protocol layer in the message status field.

Add a check also for this error condition.

Link: https://lore.kernel.org/r/20210608103056.3388-1-cristian.marussi@arm.com
Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: Cristian Marussi 
Signed-off-by: Sudeep Holla 
Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Ensure drivers provide a probe function

2021-08-08T07:04:08+00:00

commit 5e469dac326555d2038d199a6329458cc82a34e5 upstream.

The bus probe callback calls the driver callback without further
checking. Better be safe than sorry and refuse registration of a driver
without a probe function to prevent a NULL pointer exception.

Link: https://lore.kernel.org/r/20210624095059.4010157-2-sudeep.holla@arm.com
Fixes: 933c504424a2 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
Reported-by: Uwe Kleine-König 
Tested-by: Cristian Marussi 
Reviewed-by: Cristian Marussi 
Acked-by: Uwe Kleine-König 
Signed-off-by: Sudeep Holla 
Signed-off-by: Greg Kroah-Hartman

firmware: arm_scmi: Fix range check for the maximum number of pending messages

2021-07-31T06:19:38+00:00

[ Upstream commit bdb8742dc6f7c599c3d61959234fe4c23638727b ]

SCMI message headers carry a sequence number and such field is sized to
allow for MSG_TOKEN_MAX distinct numbers; moreover zero is not really an
acceptable maximum number of pending in-flight messages.

Fix accordingly the checks performed on the value exported by transports
in scmi_desc.max_msg

Link: https://lore.kernel.org/r/20210712141833.6628-3-cristian.marussi@arm.com
Reported-by: Vincent Guittot 
Signed-off-by: Cristian Marussi 
[sudeep.holla: updated the patch title and error message]
Signed-off-by: Sudeep Holla 
Signed-off-by: Sasha Levin

firmware: arm_scmi: Fix possible scmi_linux_errmap buffer overflow

2021-07-31T06:19:38+00:00

[ Upstream commit 7a691f16ccad05d770f813d9c4b4337a30c6d63f ]

The scmi_linux_errmap buffer access index is supposed to depend on the
array size to prevent element out of bounds access. It uses SCMI_ERR_MAX
to check bounds but that can mismatch with the array size. It also
changes the success into -EIO though scmi_linux_errmap is never used in
case of success, it is expected to work for success case too.

It is slightly confusing code as the negative of the error code
is used as index to the buffer. Fix it by negating it at the start and
make it more readable.

Link: https://lore.kernel.org/r/20210707135028.1869642-1-sudeep.holla@arm.com
Reported-by: kernel test robot 
Reported-by: Dan Carpenter 
Reviewed-by: Cristian Marussi 
Signed-off-by: Sudeep Holla 
Signed-off-by: Sasha Levin

firmware/efi: Tell memblock about EFI iomem reservations

2021-07-28T11:31:00+00:00

commit 2bab693a608bdf614b9fcd44083c5100f34b9f77 upstream.

kexec_load_file() relies on the memblock infrastructure to avoid
stamping over regions of memory that are essential to the survival
of the system.

However, nobody seems to agree how to flag these regions as reserved,
and (for example) EFI only publishes its reservations in /proc/iomem
for the benefit of the traditional, userspace based kexec tool.

On arm64 platforms with GICv3, this can result in the payload being
placed at the location of the LPI tables. Shock, horror!

Let's augment the EFI reservation code with a memblock_reserve() call,
protecting our dear tables from the secondary kernel invasion.

Reported-by: Moritz Fischer 
Tested-by: Moritz Fischer 
Signed-off-by: Marc Zyngier 
Cc: stable@vger.kernel.org
Cc: Ard Biesheuvel 
Cc: James Morse 
Cc: Catalin Marinas 
Cc: Will Deacon 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Greg Kroah-Hartman

efi/tpm: Differentiate missing and invalid final event log table.

2021-07-28T11:30:56+00:00

[ Upstream commit 674a9f1f6815849bfb5bf385e7da8fc198aaaba9 ]

Missing TPM final event log table is not a firmware bug.

Clearly if providing event log in the old format makes the final event
log invalid it should not be provided at least in that case.

Fixes: b4f1874c6216 ("tpm: check event log version before reading final events")
Signed-off-by: Michal Suchanek 
Reviewed-by: Jarkko Sakkinen 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Sasha Levin

firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware compatible string

2021-07-25T12:35:13+00:00

[ Upstream commit 90ae47215de3fec862aeb1a0f0e28bb505ab1351 ]

Add more generic compatible string 'marvell,armada-3700-rwtm-firmware' for
this driver, since it can also be used on other Armada 3720 devices.

Current compatible string 'cznic,turris-mox-rwtm' is kept for backward
compatibility.

Signed-off-by: Pali Rohár 
Reviewed-by: Andrew Lunn 
Signed-off-by: Gregory CLEMENT 
Signed-off-by: Sasha Levin