linux-stable.git/drivers/firmware, branch v5.13.4 Linux kernel stable tree firmware: turris-mox-rwtm: show message about HWRNG registration 2021-07-20T14:00:41+00:00 Pali Rohár pali@kernel.org 2021-05-20T11:35:20+00:00 9f5d2c5052d3a413f995bdcb944c3b1ab6d5b9cf [ 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 <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: turris-mox-rwtm: fail probing when firmware does not support hwrng 2021-07-20T14:00:41+00:00 Pali Rohár pali@kernel.org 2021-05-20T11:35:19+00:00 852ae2d33e1fecac115d4ed12091a5703c989a3e [ 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 <pali@kernel.org> Signed-off-by: Marek Behún <kabel@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: turris-mox-rwtm: report failures better 2021-07-20T14:00:40+00:00 Marek Behún kabel@kernel.org 2021-05-20T11:35:18+00:00 5f6ffd65b7dcfe69a9e64463bfff832e8b932b8a [ 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 <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: turris-mox-rwtm: fix reply status decoding function 2021-07-20T14:00:40+00:00 Marek Behún kabel@kernel.org 2021-05-20T11:35:17+00:00 aa1b734129a750d3352befda2141f49d562112ff [ 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 <kabel@kernel.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver") Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ 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 <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: arm_scmi: Add delayed response status check 2021-07-20T14:00:38+00:00 Cristian Marussi cristian.marussi@arm.com 2021-06-08T10:30:56+00:00 e1ff512116e9bdf45b687ec87b5a2c5750934db5 [ Upstream commit f1748b1ee1fa0fd1a074504045b530b62f949188 ] 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 <cristian.marussi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f1748b1ee1fa0fd1a074504045b530b62f949188 ]

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 <cristian.marussi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: arm_scmi: Reset Rx buffer to max size during async commands 2021-07-20T14:00:38+00:00 Cristian Marussi cristian.marussi@arm.com 2021-06-01T10:24:17+00:00 365987eb0d0ee3aed11424729e02857d7d7fd51e [ Upstream commit 0cb7af474e0dbb2f500c67aa62b6db9fafa74de2 ] During an async commands execution the Rx buffer length is at first set to max_msg_sz when the synchronous part of the command is first sent. However once the synchronous part completes the transport layer waits for the delayed response which will be processed using the same xfer descriptor initially allocated. Since synchronous response received at the end of the xfer will shrink the Rx buffer length to the effective payload response length, it needs to be reset again. Raise the Rx buffer length again to max_msg_sz before fetching the delayed response to ensure full response is read correctly from the shared memory. Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response") Signed-off-by: Cristian Marussi <cristian.marussi@arm.com> [sudeep.holla: moved reset to scmi_handle_response as it could race with do_xfer_with_response] Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0cb7af474e0dbb2f500c67aa62b6db9fafa74de2 ]

During an async commands execution the Rx buffer length is at first set
to max_msg_sz when the synchronous part of the command is first sent.
However once the synchronous part completes the transport layer waits
for the delayed response which will be processed using the same xfer
descriptor initially allocated. Since synchronous response received at
the end of the xfer will shrink the Rx buffer length to the effective
payload response length, it needs to be reset again.

Raise the Rx buffer length again to max_msg_sz before fetching the
delayed response to ensure full response is read correctly from the
shared memory.

Link: https://lore.kernel.org/r/20210601102421.26581-2-cristian.marussi@arm.com
Fixes: 58ecdf03dbb9 ("firmware: arm_scmi: Add support for asynchronous commands and delayed response")
Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
[sudeep.holla: moved reset to scmi_handle_response as it could race with
               do_xfer_with_response]
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
firmware: tegra: Fix error return code in tegra210_bpmp_init() 2021-07-20T14:00:38+00:00 Zhen Lei thunder.leizhen@huawei.com 2021-05-13T13:26:46+00:00 ea6ad20a538157de59dfda42383693e6ba945b12 [ Upstream commit 7fea67710e9f6a111a2c9440576f2396ccd92d57 ] When call irq_get_irq_data() to get the IRQ's irq_data failed, an appropriate error code -ENOENT should be returned. However, we directly return 'err', which records the IRQ number instead of the error code. Fixes: 139251fc2208 ("firmware: tegra: add bpmp driver for Tegra210") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7fea67710e9f6a111a2c9440576f2396ccd92d57 ]

When call irq_get_irq_data() to get the IRQ's irq_data failed, an
appropriate error code -ENOENT should be returned. However, we directly
return 'err', which records the IRQ number instead of the error code.

Fixes: 139251fc2208 ("firmware: tegra: add bpmp driver for Tegra210")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
qemu_fw_cfg: Make fw_cfg_rev_attr a proper kobj_attribute 2021-07-19T08:04:51+00:00 Nathan Chancellor nathan@kernel.org 2021-02-11T19:42:58+00:00 13b307880b66ef6e7f4eeee2a26cbbe0f8206863 commit fca41af18e10318e4de090db47d9fa7169e1bf2f upstream. fw_cfg_showrev() is called by an indirect call in kobj_attr_show(), which violates clang's CFI checking because fw_cfg_showrev()'s second parameter is 'struct attribute', whereas the ->show() member of 'struct kobj_structure' expects the second parameter to be of type 'struct kobj_attribute'. $ cat /sys/firmware/qemu_fw_cfg/rev 3 $ dmesg | grep "CFI failure" [ 26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8): Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where this would have been caught automatically by the incompatible pointer types compiler warning. Update fw_cfg_showrev() accordingly. Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device") Link: https://github.com/ClangBuiltLinux/linux/issues/1299 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Kees Cook <keescook@chromium.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit fca41af18e10318e4de090db47d9fa7169e1bf2f upstream.

fw_cfg_showrev() is called by an indirect call in kobj_attr_show(),
which violates clang's CFI checking because fw_cfg_showrev()'s second
parameter is 'struct attribute', whereas the ->show() member of 'struct
kobj_structure' expects the second parameter to be of type 'struct
kobj_attribute'.

$ cat /sys/firmware/qemu_fw_cfg/rev
3

$ dmesg | grep "CFI failure"
[   26.016832] CFI failure (target: fw_cfg_showrev+0x0/0x8):

Fix this by converting fw_cfg_rev_attr to 'struct kobj_attribute' where
this would have been caught automatically by the incompatible pointer
types compiler warning. Update fw_cfg_showrev() accordingly.

Fixes: 75f3e8e47f38 ("firmware: introduce sysfs driver for QEMU's fw_cfg device")
Link: https://github.com/ClangBuiltLinux/linux/issues/1299
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210211194258.4137998-1-nathan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
firmware: stratix10-svc: Fix a resource leak in an error handling path 2021-07-14T15:07:31+00:00 Christophe JAILLET christophe.jaillet@wanadoo.fr 2021-05-21T18:22:15+00:00 1d1edde89cb4c6dd63624b627f48cf86b210ea88 [ Upstream commit d99247f9b542533ddbf87a3481a05473b8e48194 ] If an error occurs after a successful 'kfifo_alloc()' call, it must be undone by a corresponding 'kfifo_free()' call, as already done in the remove function. While at it, move the 'platform_device_put()' call to this new error handling path and explicitly return 0 in the success path. Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/0ca3f3ab139c53e846804455a1e7599ee8ae896a.1621621271.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d99247f9b542533ddbf87a3481a05473b8e48194 ]

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

While at it, move the 'platform_device_put()' call to this new error
handling path and explicitly return 0 in the success path.

Fixes: b5dc75c915cd ("firmware: stratix10-svc: extend svc to support new RSU features")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0ca3f3ab139c53e846804455a1e7599ee8ae896a.1621621271.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'efi-urgent-for-v5.13-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/urgent 2021-05-23T09:39:02+00:00 Ingo Molnar mingo@kernel.org 2021-05-23T09:39:02+00:00 e169fba4f464760dd9734c9e39e1c2e88e374f32 Pull EFI fixes for v5.13-rc from Ard Biesheuvel: "A handful of low urgency EFI fixes accumulated over the past couple of months." Signed-off-by: Ingo Molnar <mingo@kernel.org> 
Pull EFI fixes for v5.13-rc from Ard Biesheuvel:

  "A handful of low urgency EFI fixes accumulated over the past couple of
   months."

Signed-off-by: Ingo Molnar <mingo@kernel.org>