From: Marek Behún <kabel@kernel.org> Date: 2021-03-08 15:39:15
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Marek Behún <kabel@kernel.org> Date: 2021-03-08 15:38:20
From: Pali Rohár <pali@kernel.org>
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 8 --------
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
From: Pali Rohár <pali@kernel.org>
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file.
I disagree with this patch. This firmware is specific to Turris MOX so
it is not something that should be exposed to all the Armada 3700 based
boards.
If you want you still can create an dtsi for this and include it when
needed.
Gregory
quoted hunk
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 8 --------
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
From: Marek Behún <kabel@kernel.org> Date: 2021-03-12 09:11:32
On Fri, 12 Mar 2021 09:58:34 +0100
Gregory CLEMENT [off-list ref] wrote:
Hello Marek,
quoted
From: Pali Rohár <pali@kernel.org>
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file.
I disagree with this patch. This firmware is specific to Turris MOX so
it is not something that should be exposed to all the Armada 3700 based
boards.
If you want you still can create an dtsi for this and include it when
needed.
Gregory
Gregory, we are planning to send pull-request for TF-A documentation,
adding information that people can compile the firmware with CZ.NIC's
firmware.
Since this firmware exposes HW random number generator, it is
possible that people will start using it for espressobin.
In that case this won't be specific for Turris MOX anymore.
Maybe we should add another compatible to the turris-mox-rwtm driver?
Marek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-03-12 14:48:56
On Fri, Mar 12, 2021 at 10:10:27AM +0100, Marek Behún wrote:
On Fri, 12 Mar 2021 09:58:34 +0100
Gregory CLEMENT [off-list ref] wrote:
quoted
Hello Marek,
quoted
From: Pali Rohár <pali@kernel.org>
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file.
I disagree with this patch. This firmware is specific to Turris MOX so
it is not something that should be exposed to all the Armada 3700 based
boards.
If you want you still can create an dtsi for this and include it when
needed.
Gregory
Gregory, we are planning to send pull-request for TF-A documentation,
adding information that people can compile the firmware with CZ.NIC's
firmware.
Since this firmware exposes HW random number generator, it is
possible that people will start using it for espressobin.
In that case this won't be specific for Turris MOX anymore.
Part of the problem is that it looks specific to the Turris MOX.
But please help me understand the big picture first. How is the
firmware distributed? Is the binary part of linux-firmware? How does
it get loaded? Does the firmware contain anything which is specific to
the Turris MOX? Could the hardware number generator part be split out
into a more generic sounding name blob?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org> Date: 2021-03-12 15:18:00
On Fri, 12 Mar 2021 15:48:14 +0100
Andrew Lunn [off-list ref] wrote:
On Fri, Mar 12, 2021 at 10:10:27AM +0100, Marek Behún wrote:
quoted
On Fri, 12 Mar 2021 09:58:34 +0100
Gregory CLEMENT [off-list ref] wrote:
quoted
Hello Marek,
quoted
From: Pali Rohár <pali@kernel.org>
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file.
I disagree with this patch. This firmware is specific to Turris MOX so
it is not something that should be exposed to all the Armada 3700 based
boards.
If you want you still can create an dtsi for this and include it when
needed.
Gregory
Gregory, we are planning to send pull-request for TF-A documentation,
adding information that people can compile the firmware with CZ.NIC's
firmware.
Since this firmware exposes HW random number generator, it is
possible that people will start using it for espressobin.
In that case this won't be specific for Turris MOX anymore.
Part of the problem is that it looks specific to the Turris MOX.
But please help me understand the big picture first. How is the
firmware distributed? Is the binary part of linux-firmware? How does
it get loaded? Does the firmware contain anything which is specific to
the Turris MOX? Could the hardware number generator part be split out
into a more generic sounding name blob?
Andrew
Hello Andrew,
The WTMI firmware is loaded before kernel. This firmware is loaded by
BootROM, and it is this firmware that does DDR training before loading
TF-A + U-Boot.
For example for ESPRESSObin you have several repositories you need to
create a final flash-image.bin containing this WTMI firmware + TF-A +
U-Boot. These repositories are:
trusted-firmware-a (contains documentation how to build all this)
A3700-utils-marvell
u-boot
mv-ddr-marvell
From these sources you are able to create a final flash-image.bin that
you can flash onto the SPI-NOR (or eMMC or other devices which A3720
can boot from).
The A3700-utils-marvell repository contains the code of the WTMI
firmware.
On Turris MOX this is a little bit different, because
- we have implemented the WTMI firmware differently (more mailbox
commands, HW crypto, ...)
- it supports retrieving MOX board information (MAC addresses, serial
number) stored in eFuses (this information is stored in a specific
way that in only true for MOX)
- the firmware binary must be signed by our private key in order to
boot on MOX.
This is because the secure firmware has access to an ECDSA engine
with a private key storage in eFuses (each MOX has its own private
key generated and stored into the eFuses when manufactured)
In order to disallow hackers to somehow extract the private key,
the firmware must be signed so that they cannot load arbitrary
firmware into the secure processor.
BUT
- since this firmware is able to provide HWRNG, we wanted to make it
available for other Armada 3720 boards
- we updated the code so that users can build it for non-MOX devices
- it does not have to be signed for other devices
- it does not contain MOX specific stuff for non-MOX devices
So currently when users build the flash-image.bin binary containing
WTMI firmware, they are using code from A3700-utils-marvell. This code
is split into 2 parts:
- sys_init - does HW and DDR initialization and execution of an "app"
- efuse - default "app" which is loaded by sys_init
The way it is written is that user can select a different "app" when
building, and we have updated Turris MOX firmware code to be loadable
as this "app" for sys_init. (And we have renamed it from "Turris MOX
secure firmware" to "CZ.NIC's Armada 3720 secure firmware").
Could the hardware number generator part be split out into a more
generic sounding name blob?
It basically is. As I have written above, when users build the
flash-image.bin with CZ.NIC's firmware, the prompt does not say
anything about Turris MOX. Instead it says something like
CZ.NIC's Armada 3720 Secure Firmware version build date
Running on ESPRESSObin
and currently provides only the random number generator command.
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
Marek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-03-12 15:54:11
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
quoted
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Hello Andrew! The issue is that upstream Marvell repository contains
only 'fuse.bin' application which is suitable only for fuse programming.
I think it is not correct if this Marvell fuse application start
providing other functionality not relevant to fuse programming. And
Marvell does not provide any other application (publicly). So it would
be needed to send it as another application, not part of 'fuse.bin'. And
then it complicates build system and compile options, which is already
too complicated (you need to set tons of TF-A options and prepare two
sets of cross compile toolchains).
But because application / firmware for MOX / Armada 3720 is actively
developed on different place, I do not think that it make sense to send
every change to two different locations (and wait for Marvell until
review every change and include it into their repository). Such thing
just increase maintenance cost at both sides.
For me it looks like a better solution to provide 'wtmi_app.bin'
application with HW number generator from separate repository, where it
is currently developed and where it is available for a longer time.
We are planning to send documentation update to Trusted-Firmware project
to specify how to build Armada 3720 firmware image with our application.
So people who are building Armada 3720 firmware would be able to switch
from Marvell's 'fuse.bin' application to our 'wtmi_app.bin'.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org> Date: 2021-03-12 16:33:00
On Fri, 12 Mar 2021 17:18:57 +0100
Pali Rohár [off-list ref] wrote:
On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
quoted
quoted
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Hello Andrew! The issue is that upstream Marvell repository contains
only 'fuse.bin' application which is suitable only for fuse programming.
I think it is not correct if this Marvell fuse application start
providing other functionality not relevant to fuse programming.
Why not? We can rename it to fuse+hwrng and implement hwrng there.
Maybe Konstantin will agree with such a change :)
And Marvell does not provide any other application (publicly). So it would
be needed to send it as another application, not part of 'fuse.bin'. And
then it complicates build system and compile options, which is already
too complicated (you need to set tons of TF-A options and prepare two
sets of cross compile toolchains).
But because application / firmware for MOX / Armada 3720 is actively
developed on different place, I do not think that it make sense to send
every change to two different locations (and wait for Marvell until
review every change and include it into their repository). Such thing
just increase maintenance cost at both sides.
This is a little bit better argument than the previous one. But I
think Andrew may be right in that for end-users it just complicates
things if they have more options. Better to give them one option.
For me it looks like a better solution to provide 'wtmi_app.bin'
application with HW number generator from separate repository, where it
is currently developed and where it is available for a longer time.
We are planning to send documentation update to Trusted-Firmware project
to specify how to build Armada 3720 firmware image with our application.
So people who are building Armada 3720 firmware would be able to switch
from Marvell's 'fuse.bin' application to our 'wtmi_app.bin'.
On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
quoted
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Andrew
Hello Andrew!
I do not think that renaming driver is the best option. For future it
would complicate backporting patches to stable kernel and also it would
make usage of 'gitk' harder as this tool cannot automatically track file
renames.
I saw that kernel drivers lot of times got support for a new HW but
driver name was not changed (maybe for backward compatibility, maybe to
simplify things).
Andrew, now when you got a full picture of this problem, would you
be willing to accept these patches? Or do you require some changes?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-03-15 12:09:05
On Mon, Mar 15, 2021 at 11:14:54AM +0100, Pali Rohár wrote:
On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
quoted
quoted
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Andrew
Hello Andrew!
I do not think that renaming driver is the best option. For future it
would complicate backporting patches to stable kernel and also it would
make usage of 'gitk' harder as this tool cannot automatically track file
renames.
Hi Pali
I'm not suggesting renaming the .c file.
What would be good is to add additional compatible strings. Add a more
generic compatible. What goes into the .dtsi should use the generic
name. Also, the node names should also be generic, since the node name
is probably not used anywhere, just the compatible string. Keep the
current compatible in the driver, for backwards compatibility with
older DT blobs.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Monday 15 March 2021 13:08:16 Andrew Lunn wrote:
On Mon, Mar 15, 2021 at 11:14:54AM +0100, Pali Rohár wrote:
quoted
On Friday 12 March 2021 16:53:32 Andrew Lunn wrote:
quoted
quoted
So theoretically the turris-mox-rwtm driver can be renamed into
something else and we can add a different compatible in order not to
sound so turris-mox specific.
That would be a good idea. And if possible, try to push the hardware
random number code upstream in the firmware repos, so everybody gets
it by default, not just those using your build. Who is responsible for
upstream? Marvell?
Andrew
Hello Andrew!
I do not think that renaming driver is the best option. For future it
would complicate backporting patches to stable kernel and also it would
make usage of 'gitk' harder as this tool cannot automatically track file
renames.
Hi Pali
I'm not suggesting renaming the .c file.
What would be good is to add additional compatible strings. Add a more
generic compatible. What goes into the .dtsi should use the generic
name. Also, the node names should also be generic, since the node name
is probably not used anywhere, just the compatible string. Keep the
current compatible in the driver, for backwards compatibility with
older DT blobs.
Ok! What about compatible string "marvell,armada-3700-rwtm-firmware"?
Mailbox layer which is used by this driver has compatible string
"marvell,armada-3700-rwtm-mailbox", so name is similar.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org> Date: 2021-03-08 15:39:16
From: Pali Rohár <pali@kernel.org>
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.
This makes it possible to put this driver's compatible into generic
armada-37xx device tree, to be available for other Armada 3720 devices
besides Turris MOX. If they use the rWTM firmware from CZ.NIC, they will
have HWRNG available, and if not, the driver won't be complaining.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Marek Behún <kabel@kernel.org>
---
drivers/firmware/turris-mox-rwtm.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
@@ -260,6 +260,27 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)return0;}+staticintcheck_get_random_support(structmox_rwtm*rwtm)+{+structarmada_37xx_rwtm_tx_msgmsg;+intret;++msg.command=MBOX_CMD_GET_RANDOM;+msg.args[0]=1;+msg.args[1]=rwtm->buf_phys;+msg.args[2]=4;++ret=mbox_send_message(rwtm->mbox,&msg);+if(ret<0)+returnret;++ret=wait_for_completion_timeout(&rwtm->cmd_done,HZ/2);+if(ret<0)+returnret;++returnmox_get_status(MBOX_CMD_GET_RANDOM,rwtm->reply.retval);+}+staticintmox_hwrng_read(structhwrng*rng,void*data,size_tmax,boolwait){structmox_rwtm*rwtm=(structmox_rwtm*)rng->priv;
@@ -497,6 +518,13 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)if(ret<0)dev_warn(dev,"Cannot read board information: %i\n",ret);+ret=check_get_random_support(rwtm);+if(ret<0){+dev_notice(dev,+"Firmware does not support the GET_RANDOM command\n");+gotofree_channel;+}+rwtm->hwrng.name=DRIVER_NAME"_hwrng";rwtm->hwrng.read=mox_hwrng_read;rwtm->hwrng.priv=(unsignedlong)rwtm;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org> Date: 2021-03-08 15:39:27
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 non-CZ.NIC boards that do not have manufacturing information
burned.
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -204,11 +204,14 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_BOARD_INFO,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board does not have manufacturing information burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the BOARD_INFO command\n");+}elseif(ret<0){+returnret;}else{rwtm->serial_number=reply->status[1];rwtm->serial_number<<=32;
@@ -237,10 +240,13 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_ECDSA_PUB_KEY,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board has no public key burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the ECDSA_PUB_KEY command\n");+}elseif(ret<0){+returnret;}else{u32*s=reply->status;
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org>
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Marek Behún <kabel@kernel.org>
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 non-CZ.NIC boards that do not have manufacturing information
burned.
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -204,11 +204,14 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_BOARD_INFO,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board does not have manufacturing information burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the BOARD_INFO command\n");+}elseif(ret<0){+returnret;}else{rwtm->serial_number=reply->status[1];rwtm->serial_number<<=32;
@@ -237,10 +240,13 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_ECDSA_PUB_KEY,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board has no public key burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the ECDSA_PUB_KEY command\n");+}elseif(ret<0){+returnret;}else{u32*s=reply->status;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 2 ++
1 file changed, 2 insertions(+)
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.
This makes it possible to put this driver's compatible into generic
armada-37xx device tree, to be available for other Armada 3720 devices
besides Turris MOX. If they use the rWTM firmware from CZ.NIC, they will
have HWRNG available, and if not, the driver won't be complaining.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Marek Behún <kabel@kernel.org>
---
drivers/firmware/turris-mox-rwtm.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
@@ -260,6 +260,27 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)return0;}+staticintcheck_get_random_support(structmox_rwtm*rwtm)+{+structarmada_37xx_rwtm_tx_msgmsg;+intret;++msg.command=MBOX_CMD_GET_RANDOM;+msg.args[0]=1;+msg.args[1]=rwtm->buf_phys;+msg.args[2]=4;++ret=mbox_send_message(rwtm->mbox,&msg);+if(ret<0)+returnret;++ret=wait_for_completion_timeout(&rwtm->cmd_done,HZ/2);+if(ret<0)+returnret;++returnmox_get_status(MBOX_CMD_GET_RANDOM,rwtm->reply.retval);+}+staticintmox_hwrng_read(structhwrng*rng,void*data,size_tmax,boolwait){structmox_rwtm*rwtm=(structmox_rwtm*)rng->priv;
@@ -497,6 +518,13 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)if(ret<0)dev_warn(dev,"Cannot read board information: %i\n",ret);+ret=check_get_random_support(rwtm);+if(ret<0){+dev_notice(dev,+"Firmware does not support the GET_RANDOM command\n");+gotofree_channel;+}+rwtm->hwrng.name=DRIVER_NAME"_hwrng";rwtm->hwrng.read=mox_hwrng_read;rwtm->hwrng.priv=(unsignedlong)rwtm;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
We are also planning to work on extending this driver to support
accessing OTP, which will also work with Marvell's default WTMI
firmware.
---
drivers/firmware/turris-mox-rwtm.c | 1 +
1 file changed, 1 insertion(+)
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 8 --------
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
@@ -107,14 +107,6 @@/* enabled by U-Boot if SFP module is present */status="disabled";};--firmware{-turris-mox-rwtm{-compatible="cznic,turris-mox-rwtm";-mboxes=<&rwtm0>;-status="okay";-};-};};&i2c0{
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-03 12:22:58
On Thu, Apr 29, 2021 at 10:36:31AM +0200, Pali Rohár wrote:
From: Marek Behún <kabel@kernel.org>
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
You have put a fixes tag here, meaning you want it in stable? How does
dead code elimination fulfil the stable requirements?
Do any of these changes contain real fixes?
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org> Date: 2021-05-05 16:04:41
On Mon, 3 May 2021 14:22:49 +0200
Andrew Lunn [off-list ref] wrote:
On Thu, Apr 29, 2021 at 10:36:31AM +0200, Pali Rohár wrote:
quoted
From: Marek Behún <kabel@kernel.org>
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
You have put a fixes tag here, meaning you want it in stable? How does
dead code elimination fulfil the stable requirements?
Do any of these changes contain real fixes?
Andrew
Andrew, this is not dead code elimination. Rather it is that there is
dead code path due to an incorrect check. By correcting the check, the
dead code path becomes alive and starts reporting errors correctly.
This fix is nedeed in stable so that stable will report errors
correctly.
Marek
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-05 16:20:52
On Wed, May 05, 2021 at 06:04:33PM +0200, Marek Behún wrote:
On Mon, 3 May 2021 14:22:49 +0200
Andrew Lunn [off-list ref] wrote:
quoted
On Thu, Apr 29, 2021 at 10:36:31AM +0200, Pali Rohár wrote:
quoted
From: Marek Behún <kabel@kernel.org>
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
You have put a fixes tag here, meaning you want it in stable? How does
dead code elimination fulfil the stable requirements?
Do any of these changes contain real fixes?
Andrew
Andrew, this is not dead code elimination.
Please word you commit message differently.
The status decoding function mox_get_status() currently contains an
incorrect check: ...
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wednesday 05 May 2021 18:20:46 Andrew Lunn wrote:
On Wed, May 05, 2021 at 06:04:33PM +0200, Marek Behún wrote:
quoted
On Mon, 3 May 2021 14:22:49 +0200
Andrew Lunn [off-list ref] wrote:
quoted
On Thu, Apr 29, 2021 at 10:36:31AM +0200, Pali Rohár wrote:
quoted
From: Marek Behún <kabel@kernel.org>
The status decoding function mox_get_status() currently contains a dead
code path: 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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
You have put a fixes tag here, meaning you want it in stable? How does
dead code elimination fulfil the stable requirements?
Do any of these changes contain real fixes?
Andrew
Andrew, this is not dead code elimination.
Please word you commit message differently.
The status decoding function mox_get_status() currently contains an
incorrect check: ...
Andrew
Andrew, Marek has already updated commit message and I have sent a new
version v3 of this patch series with this update. It is OK now?
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Marek Behún <kabel@kernel.org>
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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
From: Marek Behún <kabel@kernel.org>
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 non-CZ.NIC boards that do not have manufacturing information
burned.
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -204,11 +204,14 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_BOARD_INFO,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board does not have manufacturing information burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the BOARD_INFO command\n");+}elseif(ret<0){+returnret;}else{rwtm->serial_number=reply->status[1];rwtm->serial_number<<=32;
@@ -237,10 +240,13 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_ECDSA_PUB_KEY,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board has no public key burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the ECDSA_PUB_KEY command\n");+}elseif(ret<0){+returnret;}else{u32*s=reply->status;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 2 ++
1 file changed, 2 insertions(+)
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.
This makes it possible to put this driver's compatible into generic
armada-37xx device tree, to be available for other Armada 3720 devices
besides Turris MOX. If they use the rWTM firmware from CZ.NIC, they will
have HWRNG available, and if not, the driver won't be complaining.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Signed-off-by: Marek Behún <kabel@kernel.org>
---
drivers/firmware/turris-mox-rwtm.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
@@ -260,6 +260,27 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)return0;}+staticintcheck_get_random_support(structmox_rwtm*rwtm)+{+structarmada_37xx_rwtm_tx_msgmsg;+intret;++msg.command=MBOX_CMD_GET_RANDOM;+msg.args[0]=1;+msg.args[1]=rwtm->buf_phys;+msg.args[2]=4;++ret=mbox_send_message(rwtm->mbox,&msg);+if(ret<0)+returnret;++ret=wait_for_completion_timeout(&rwtm->cmd_done,HZ/2);+if(ret<0)+returnret;++returnmox_get_status(MBOX_CMD_GET_RANDOM,rwtm->reply.retval);+}+staticintmox_hwrng_read(structhwrng*rng,void*data,size_tmax,boolwait){structmox_rwtm*rwtm=(structmox_rwtm*)rng->priv;
@@ -497,6 +518,13 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)if(ret<0)dev_warn(dev,"Cannot read board information: %i\n",ret);+ret=check_get_random_support(rwtm);+if(ret<0){+dev_notice(dev,+"Firmware does not support the GET_RANDOM command\n");+gotofree_channel;+}+rwtm->hwrng.name=DRIVER_NAME"_hwrng";rwtm->hwrng.read=mox_hwrng_read;rwtm->hwrng.priv=(unsignedlong)rwtm;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-12 00:56:17
On Thu, May 06, 2021 at 11:07:59AM +0200, Pali Rohár wrote:
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.
This makes it possible to put this driver's compatible into generic
armada-37xx device tree, to be available for other Armada 3720 devices
besides Turris MOX. If they use the rWTM firmware from CZ.NIC, they will
have HWRNG available, and if not, the driver won't be complaining.
We start getting into questions of if this is relevant for stable.
Running Turris MOX with plain Marvell rWTM will spam the log. So i
would say it is a fix, for that situation.
However, i would drop the second part of the description. Making the
Turris MOX firmware work on none Turris MOX hardware is a new feature,
and so not applicable to stable.
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wednesday 12 May 2021 02:56:09 Andrew Lunn wrote:
However, i would drop the second part of the description. Making the
Turris MOX firmware work on none Turris MOX hardware is a new feature,
and so not applicable to stable.
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 <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
We are also planning to work on extending this driver to support
accessing OTP, which will also work with Marvell's default WTMI
firmware.
---
drivers/firmware/turris-mox-rwtm.c | 1 +
1 file changed, 1 insertion(+)
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 8 --------
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
2 files changed, 8 insertions(+), 8 deletions(-)
@@ -107,14 +107,6 @@/* enabled by U-Boot if SFP module is present */status="disabled";};--firmware{-turris-mox-rwtm{-compatible="cznic,turris-mox-rwtm";-mboxes=<&rwtm0>;-status="okay";-};-};};&i2c0{
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-12 00:59:29
On Thu, May 06, 2021 at 11:08:02AM +0200, Pali Rohár wrote:
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This is a new feature, not a fix. Please split this patchset up into
fixes, which get applied to stable, and new features which will get
merged during the next merge window.
Thanks
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Wednesday 12 May 2021 02:59:24 Andrew Lunn wrote:
On Thu, May 06, 2021 at 11:08:02AM +0200, Pali Rohár wrote:
quoted
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This is a new feature, not a fix. Please split this patchset up into
fixes, which get applied to stable, and new features which will get
merged during the next merge window.
Done, I have split patches into two patch series, so they can be
reviewed and merged separately.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-12 00:50:00
On Thu, May 06, 2021 at 11:07:57AM +0200, Pali Rohár wrote:
From: Marek Behún <kabel@kernel.org>
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>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
These two patches add support for using turris-mox-rwtm driver on any
Armada 3720 board. They are just adding a new compatible string.
Per Andrew's request I have split them from V3 series, so they can be
reviewed separately.
These patches are intended for next merge window.
I suppose that in future these patches may be backported into stable
kernel releases as in my opinion they match stable rules condition:
"New device IDs and quirks are also accepted". New compatible string
is basically new device id. Therefore I put into these patches also
Fixes/CC:stable tags. If you have different opinion on this, let me
know.
Pali Rohár (2):
firmware: turris-mox-rwtm: add marvell,armada-3700-rwtm-firmware
compatible string
arm64: dts: marvell: armada-37xx: move firmware node to generic dtsi
file
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 6 ++----
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
drivers/firmware/turris-mox-rwtm.c | 1 +
3 files changed, 11 insertions(+), 4 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 1 +
1 file changed, 1 insertion(+)
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-21 01:41:37
On Thu, May 20, 2021 at 01:38:43PM +0200, Pali Rohár wrote:
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 <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Since this is intended for the next merge window, it is clearly not a
fix. Please drop the fixes tag.
Otherwise:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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 <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
Applied on mvebu/drivers (I removed the Fixes line)
Thanks,
Gregory
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
Turris MOX DTS file contains also old compatible string for backward
compatibility.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
---
arch/arm64/boot/dts/marvell/armada-3720-turris-mox.dts | 6 ++----
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 8 ++++++++
2 files changed, 10 insertions(+), 4 deletions(-)
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-21 01:43:00
On Thu, May 20, 2021 at 01:38:44PM +0200, Pali Rohár wrote:
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
Turris MOX DTS file contains also old compatible string for backward
compatibility.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
Please drop stable. It is a new feature, not a fix.
Otherwise
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Move the turris-mox-rwtm firmware node from Turris MOX' device tree into
the generic armada-37xx.dtsi file and use the generic compatible string
'marvell,armada-3700-rwtm-firmware' instead of the current one.
Turris MOX DTS file contains also old compatible string for backward
compatibility.
The Turris MOX rWTM firmware can be used on any Armada 37xx device,
giving them access to the rWTM hardware random number generator, which
is otherwise unavailable.
This change allows Linux to load the turris-mox-rwtm.ko module on these
boards.
Tested on ESPRESSObin v5 with both default Marvell WTMI firmware and
CZ.NIC's firmware. With default WTMI firmware the turris-mox-rwtm fails
to probe, while with CZ.NIC's firmware it registers the HW random number
generator.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Cc: <redacted> # 5.4+: 46d2f6d0c99f ("arm64: dts: armada-3720-turris-mox: add firmware node")
Applied on mvebu/dt64 (I removed the Fixes line)
Thanks,
Gregory
These 4 patches are just fixups. Per Andrew's request I have split them
from V3 series, so they can be applied to stable.
Marek Behún (2):
firmware: turris-mox-rwtm: fix reply status decoding function
firmware: turris-mox-rwtm: report failures better
Pali Rohár (2):
firmware: turris-mox-rwtm: fail probing when firmware does not support
hwrng
firmware: turris-mox-rwtm: show message about HWRNG registration
drivers/firmware/turris-mox-rwtm.c | 55 +++++++++++++++++++++++++-----
1 file changed, 47 insertions(+), 8 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 2 ++
1 file changed, 2 insertions(+)
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-21 01:40:14
On Thu, May 20, 2021 at 01:35:20PM +0200, Pali Rohár wrote:
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
From: Marek Behún <kabel@kernel.org>
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.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
@@ -204,11 +204,14 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_BOARD_INFO,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board does not have manufacturing information burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the BOARD_INFO command\n");+}elseif(ret<0){+returnret;}else{rwtm->serial_number=reply->status[1];rwtm->serial_number<<=32;
@@ -237,10 +240,13 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)returnret;ret=mox_get_status(MBOX_CMD_ECDSA_PUB_KEY,reply->retval);-if(ret<0&&ret!=-ENODATA){-returnret;-}elseif(ret==-ENODATA){+if(ret==-ENODATA){dev_warn(rwtm->dev,"Board has no public key burned!\n");+}elseif(ret==-ENOSYS){+dev_notice(rwtm->dev,+"Firmware does not support the ECDSA_PUB_KEY command\n");+}elseif(ret<0){+returnret;}else{u32*s=reply->status;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Andrew Lunn <andrew@lunn.ch> Date: 2021-05-21 01:38:42
On Thu, May 20, 2021 at 01:35:18PM +0200, Pali Rohár wrote:
From: Marek Behún <kabel@kernel.org>
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.
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Pali Rohár <pali@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
From: Marek Behún <kabel@kernel.org>
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")
---
drivers/firmware/turris-mox-rwtm.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
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.
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Fixes: 389711b37493 ("firmware: Add Turris Mox rWTM firmware driver")
---
drivers/firmware/turris-mox-rwtm.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
@@ -260,6 +260,27 @@ static int mox_get_board_info(struct mox_rwtm *rwtm)return0;}+staticintcheck_get_random_support(structmox_rwtm*rwtm)+{+structarmada_37xx_rwtm_tx_msgmsg;+intret;++msg.command=MBOX_CMD_GET_RANDOM;+msg.args[0]=1;+msg.args[1]=rwtm->buf_phys;+msg.args[2]=4;++ret=mbox_send_message(rwtm->mbox,&msg);+if(ret<0)+returnret;++ret=wait_for_completion_timeout(&rwtm->cmd_done,HZ/2);+if(ret<0)+returnret;++returnmox_get_status(MBOX_CMD_GET_RANDOM,rwtm->reply.retval);+}+staticintmox_hwrng_read(structhwrng*rng,void*data,size_tmax,boolwait){structmox_rwtm*rwtm=(structmox_rwtm*)rng->priv;
@@ -497,6 +518,13 @@ static int turris_mox_rwtm_probe(struct platform_device *pdev)if(ret<0)dev_warn(dev,"Cannot read board information: %i\n",ret);+ret=check_get_random_support(rwtm);+if(ret<0){+dev_notice(dev,+"Firmware does not support the GET_RANDOM command\n");+gotofree_channel;+}+rwtm->hwrng.name=DRIVER_NAME"_hwrng";rwtm->hwrng.read=mox_hwrng_read;rwtm->hwrng.priv=(unsignedlong)rwtm;
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel