user/sven/linux.git/drivers/firmware, branch v5.4.140

firmware: arm_scmi: Add delayed response status check

2021-08-08T07:04:08Z

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:08Z

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:38Z

[ 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:38Z

[ 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:00Z

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:56Z

[ 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:13Z

[ 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

firmware: tegra: bpmp: Fix Tegra234-only builds

2021-07-25T12:35:12Z

[ Upstream commit bd778b893963d67d7eb01f49d84ffcd3eaf229dd ] The tegra186_bpmp_ops symbol is used on Tegra234, so make sure it's available. Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

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

2021-07-20T14:10:53Z

[ 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:10:53Z

[ 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