[PATCH v2 0/2] nvmem: rmem: Make reserved region name unique

[PATCH v2 0/2] nvmem: rmem: Make reserved region name unique

[Ivan T. Ivanov]

They could be multiple reserved memory regions,
so let's make their names unique.

This fixes following kernel error:

[    9.831285] sysfs: cannot create duplicate filename '/bus/nvmem/devices/rmem0'
[    9.831304] CPU: 3 PID: 467 Comm: (udev-worker) Not tainted 6.2.9-1-default #1 openSUSE Tumbleweed a4aeb3a90c0f23041a8a7944b12739b07585f009
[    9.831326] Hardware name: raspberrypi rpi/rpi, BIOS 2023.01 01/01/2023
[    9.831335] Call trace:
[    9.831343]  dump_backtrace+0xe4/0x140
[    9.831366]  show_stack+0x20/0x30
[    9.831379]  dump_stack_lvl+0x64/0x80
[    9.831398]  dump_stack+0x18/0x34
[    9.831410]  sysfs_warn_dup+0x6c/0x90
[    9.831424]  sysfs_do_create_link_sd+0xf8/0x100
[    9.831437]  sysfs_create_link+0x28/0x50
[    9.831449]  bus_add_device+0x70/0x190
[    9.831468]  device_add+0x3e8/0x84c
[    9.831481]  nvmem_register+0x85c/0x9f0
[    9.831500]  devm_nvmem_register+0x24/0x70
[    9.831517]  rmem_probe+0xa0/0xf4 [nvmem_rmem 649243b01e5e28ee94e4dd53bd13b6ececa836f8]
[    9.831555]  platform_probe+0x70/0xd0
[    9.831566]  really_probe+0xc8/0x3e4
[    9.831582]  __driver_probe_device+0x84/0x190
[    9.831598]  driver_probe_device+0x44/0x11c
[    9.831613]  __driver_attach+0xf8/0x200
[    9.831629]  bus_for_each_dev+0x78/0xd0
[    9.831643]  driver_attach+0x2c/0x40
[    9.831657]  bus_add_driver+0x188/0x250
[    9.831672]  driver_register+0x80/0x13c
[    9.831688]  __platform_driver_register+0x30/0x40
[    9.831699]  rmem_driver_init+0x28/0x1000 [nvmem_rmem 649243b01e5e28ee94e4dd53bd13b6ececa836f8]
[    9.831727]  do_one_initcall+0x48/0x2bc
[    9.831740]  do_init_module+0x50/0x1f0
[    9.831753]  load_module+0x1e54/0x2250
[    9.831763]  __do_sys_init_module+0x2ac/0x2f0
[    9.831774]  __arm64_sys_init_module+0x24/0x30
[    9.831785]  invoke_syscall+0x78/0x100
[    9.831803]  el0_svc_common.constprop.0+0x15c/0x180
[    9.831820]  do_el0_svc+0x40/0xb0
[    9.831836]  el0_svc+0x34/0x134
[    9.831850]  el0t_64_sync_handler+0x114/0x120
[    9.831865]  el0t_64_sync+0x1a4/0x1a8
[    9.831956] rmem: probe of 3ef62ce0.nvram failed with error -17

Some background information about the issue could be found here:
https://bugzilla.suse.com/show_bug.cgi?id=1206846

Changes since v1

I dig into Raspberry Github repository and found original patches
from Tim and Phil which add new region and fix rmem driver.

Patch 1 - use NVMEM_DEVID_AUTO instead making region name unique from
the driver itself.

Patch 2 - New one.

Phil Elwell (1):
  nvmem: rmem: Use NVMEM_DEVID_AUTO

Tim Gover (1):
  ARM: dts: Add nvmem node for BCM2711 bootloader public key

 arch/arm/boot/dts/bcm2711-rpi.dtsi | 14 ++++++++++++++
 drivers/nvmem/rmem.c               |  1 +
 2 files changed, 15 insertions(+)

-- 
2.35.3

[PATCH v2 1/2] nvmem: rmem: Use NVMEM_DEVID_AUTO

[Ivan T. Ivanov]

From: Phil Elwell <phil@raspberrypi.com>

It is reasonable to declare multiple nvmem blocks. Unless a unique 'id'
is passed in for each block there may be name clashes.

Avoid this by using the magic token NVMEM_DEVID_AUTO.

Fixes: 5a3fa75a4d9cb ("nvmem: Add driver to expose reserved memory as nvmem")

Signed-off-by: Phil Elwell <phil@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 drivers/nvmem/rmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nvmem/rmem.c b/drivers/nvmem/rmem.c
index 80cb187f1481..752d0bf4445e 100644
--- a/drivers/nvmem/rmem.c
+++ b/drivers/nvmem/rmem.c
@@ -71,6 +71,7 @@ static int rmem_probe(struct platform_device *pdev)
 	config.dev = dev;
 	config.priv = priv;
 	config.name = "rmem";
+	config.id = NVMEM_DEVID_AUTO;
 	config.size = mem->size;
 	config.reg_read = rmem_read;
 
-- 
2.35.3

[PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Ivan T. Ivanov]

From: Tim Gover <tim.gover@raspberrypi.com>

Make a copy of the bootloader secure-boot public key available to the OS
via an nvmem node. The placement information is populated by the
Raspberry Pi firmware if a public key is present in the BCM2711
bootloader EEPROM.

Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
---
 arch/arm/boot/dts/bcm2711-rpi.dtsi | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2711-rpi.dtsi b/arch/arm/boot/dts/bcm2711-rpi.dtsi
index 98817a6675b9..e30fbe84f9c3 100644
--- a/arch/arm/boot/dts/bcm2711-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2711-rpi.dtsi
@@ -15,6 +15,7 @@ aliases {
 		ethernet0 = &genet;
 		pcie0 = &pcie0;
 		blconfig = &blconfig;
+		blpubkey = &blpubkey;
 	};
 };
 
@@ -67,6 +68,19 @@ blconfig: nvram@0 {
 		no-map;
 		status = "disabled";
 	};
+
+	/*
+	 * RPi4 will copy the binary public key blob (if present) from the bootloader
+	 * into memory for use by the OS.
+	 */
+	blpubkey: nvram@1 {
+		compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
+		#address-cells = <1>;
+		#size-cells = <1>;
+		reg = <0x0 0x0 0x0>;
+		no-map;
+		status = "disabled";
+	};
 };
 
 &v3d {
-- 
2.35.3

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Stefan Wahren]

Hi Ivan,

Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
> From: Tim Gover <tim.gover@raspberrypi.com>
> 
> Make a copy of the bootloader secure-boot public key available to the OS
> via an nvmem node. The placement information is populated by the
> Raspberry Pi firmware if a public key is present in the BCM2711
> bootloader EEPROM.

It would be nice to have a helpful link like:
https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes

> 
> Signed-off-by: Tim Gover <tim.gover@raspberrypi.com>
> Signed-off-by: Ivan T. Ivanov <iivanov@suse.de>
> ---
>   arch/arm/boot/dts/bcm2711-rpi.dtsi | 14 ++++++++++++++
>   1 file changed, 14 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm2711-rpi.dtsi b/arch/arm/boot/dts/bcm2711-rpi.dtsi
> index 98817a6675b9..e30fbe84f9c3 100644
> --- a/arch/arm/boot/dts/bcm2711-rpi.dtsi
> +++ b/arch/arm/boot/dts/bcm2711-rpi.dtsi
> @@ -15,6 +15,7 @@ aliases {
>   		ethernet0 = &genet;
>   		pcie0 = &pcie0;
>   		blconfig = &blconfig;
> +		blpubkey = &blpubkey;
>   	};
>   };
>   
> @@ -67,6 +68,19 @@ blconfig: nvram@0 {
>   		no-map;
>   		status = "disabled";
>   	};
> +
> +	/*
> +	 * RPi4 will copy the binary public key blob (if present) from the bootloader
> +	 * into memory for use by the OS.
> +	 */
> +	blpubkey: nvram@1 {
> +		compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";

Yes this looks better, but this introduce a new dtbs_check issue. The 
new compatible must be documented in 
Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch 
and reviewed by the DT guys.

Btw better use linux-arm-kernel list instead of lkml

Best regards

> +		#address-cells = <1>;
> +		#size-cells = <1>;
> +		reg = <0x0 0x0 0x0>;
> +		no-map;
> +		status = "disabled";
> +	};
>   };
>   
>   &v3d {

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Ivan T. Ivanov]

On 04-13 18:15, Stefan Wahren wrote:
> 
> Hi Ivan,
> 
> Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
> > From: Tim Gover <tim.gover@raspberrypi.com>
> > 
> > Make a copy of the bootloader secure-boot public key available to the OS
> > via an nvmem node. The placement information is populated by the
> > Raspberry Pi firmware if a public key is present in the BCM2711
> > bootloader EEPROM.
> 
> It would be nice to have a helpful link like:
> https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes

Yep, make sense.

> > +
> > +	/*
> > +	 * RPi4 will copy the binary public key blob (if present) from the bootloader
> > +	 * into memory for use by the OS.
> > +	 */
> > +	blpubkey: nvram@1 {
> > +		compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
> 
> Yes this looks better, but this introduce a new dtbs_check issue. The new

Oops, yes, I forgot to make this check.

> compatible must be documented in
> Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch and
> reviewed by the DT guys.

Or I can drop the new compatible string altogether? It looks like
only alias is strictly required?! Tim Gover is this correct?

Regards,
Ivan

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Stefan Wahren]

Hi Ivan,

Am 13.04.23 um 20:18 schrieb Ivan T. Ivanov:
> On 04-13 18:15, Stefan Wahren wrote:
>>
>> Hi Ivan,
>>
>> Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
>>> From: Tim Gover <tim.gover@raspberrypi.com>
>>>
>>> Make a copy of the bootloader secure-boot public key available to the OS
>>> via an nvmem node. The placement information is populated by the
>>> Raspberry Pi firmware if a public key is present in the BCM2711
>>> bootloader EEPROM.
>>
>> It would be nice to have a helpful link like:
>> https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
> 
> Yep, make sense.
> 
>>> +
>>> +	/*
>>> +	 * RPi4 will copy the binary public key blob (if present) from the bootloader
>>> +	 * into memory for use by the OS.
>>> +	 */
>>> +	blpubkey: nvram@1 {
>>> +		compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
>>
>> Yes this looks better, but this introduce a new dtbs_check issue. The new
> 
> Oops, yes, I forgot to make this check.
> 
>> compatible must be documented in
>> Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch and
>> reviewed by the DT guys.
> 
> Or I can drop the new compatible string altogether? It looks like
> only alias is strictly required?! Tim Gover is this correct?

i cannot speak for the firmware side, but i think we should try to keep 
it compatible with the vendor DTB here.

> 
> Regards,
> Ivan
> 

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Tim Gover]

On Thu, 13 Apr 2023 at 19:44, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>
> Hi Ivan,
>
> Am 13.04.23 um 20:18 schrieb Ivan T. Ivanov:
> > On 04-13 18:15, Stefan Wahren wrote:
> >>
> >> Hi Ivan,
> >>
> >> Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
> >>> From: Tim Gover <tim.gover@raspberrypi.com>
> >>>
> >>> Make a copy of the bootloader secure-boot public key available to the OS
> >>> via an nvmem node. The placement information is populated by the
> >>> Raspberry Pi firmware if a public key is present in the BCM2711
> >>> bootloader EEPROM.
> >>
> >> It would be nice to have a helpful link like:
> >> https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
> >
> > Yep, make sense.
> >
> >>> +
> >>> +   /*
> >>> +    * RPi4 will copy the binary public key blob (if present) from the bootloader
> >>> +    * into memory for use by the OS.
> >>> +    */
> >>> +   blpubkey: nvram@1 {
> >>> +           compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
> >>
> >> Yes this looks better, but this introduce a new dtbs_check issue. The new
> >
> > Oops, yes, I forgot to make this check.
> >
> >> compatible must be documented in
> >> Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch and
> >> reviewed by the DT guys.
> >
> > Or I can drop the new compatible string altogether? It looks like
> > only alias is strictly required?! Tim Gover is this correct?
>
> i cannot speak for the firmware side, but i think we should try to keep
> it compatible with the vendor DTB here.
>

The firmware doesn't look at the compatible string. It locates the
nodes to update using the 'blconfig' and 'blpubkey' aliases. Userspace
scripts (including the documentation example) should also use these
aliases.
Therefore, I don't think it matters if the compatible strings is
modified, but I won't pretend to know what the correct DT style is
here :)

Tim

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Stefan Wahren]

Hi,

Am 13.04.23 um 21:28 schrieb Tim Gover:
> On Thu, 13 Apr 2023 at 19:44, Stefan Wahren <stefan.wahren@i2se.com> wrote:
>>
>> Hi Ivan,
>>
>> Am 13.04.23 um 20:18 schrieb Ivan T. Ivanov:
>>> On 04-13 18:15, Stefan Wahren wrote:
>>>>
>>>> Hi Ivan,
>>>>
>>>> Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
>>>>> From: Tim Gover <tim.gover@raspberrypi.com>
>>>>>
>>>>> Make a copy of the bootloader secure-boot public key available to the OS
>>>>> via an nvmem node. The placement information is populated by the
>>>>> Raspberry Pi firmware if a public key is present in the BCM2711
>>>>> bootloader EEPROM.
>>>>
>>>> It would be nice to have a helpful link like:
>>>> https://www.raspberrypi.com/documentation/computers/configuration.html#nvmem-nodes
>>>
>>> Yep, make sense.
>>>
>>>>> +
>>>>> +   /*
>>>>> +    * RPi4 will copy the binary public key blob (if present) from the bootloader
>>>>> +    * into memory for use by the OS.
>>>>> +    */
>>>>> +   blpubkey: nvram@1 {
>>>>> +           compatible = "raspberrypi,bootloader-public-key", "nvmem-rmem";
>>>>
>>>> Yes this looks better, but this introduce a new dtbs_check issue. The new
>>>
>>> Oops, yes, I forgot to make this check.
>>>
>>>> compatible must be documented in
>>>> Documentation/devicetree/bindings/nvmem/rmem.yaml in a separate patch and
>>>> reviewed by the DT guys.
>>>
>>> Or I can drop the new compatible string altogether? It looks like
>>> only alias is strictly required?! Tim Gover is this correct?
>>
>> i cannot speak for the firmware side, but i think we should try to keep
>> it compatible with the vendor DTB here.
>>
> 
> The firmware doesn't look at the compatible string. It locates the
> nodes to update using the 'blconfig' and 'blpubkey' aliases. Userspace
> scripts (including the documentation example) should also use these
> aliases.
> Therefore, I don't think it matters if the compatible strings is
> modified, but I won't pretend to know what the correct DT style is
> here :)

okay, regardless of the compatible string the patch must be send to the 
DT maintainers and the devicetree mailing list otherwise they don't have 
any chance to review.

Thanks

> 
> Tim

Re: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key

[Ivan T. Ivanov]

Hi,

On 04-16 15:11, Stefan Wahren wrote:
> > > > 
> > > > Or I can drop the new compatible string altogether? It looks like
> > > > only alias is strictly required?! Tim Gover is this correct?
> > > 
> > > i cannot speak for the firmware side, but i think we should try to keep
> > > it compatible with the vendor DTB here.
> > > 
> > 
> > The firmware doesn't look at the compatible string. It locates the
> > nodes to update using the 'blconfig' and 'blpubkey' aliases. Userspace
> > scripts (including the documentation example) should also use these
> > aliases.
> > Therefore, I don't think it matters if the compatible strings is
> > modified, but I won't pretend to know what the correct DT style is
> > here :)

Ok. Perhaps Stefan have a point and will be better if we keep things 
in sync between vendor DTS and upstream one.

> 
> okay, regardless of the compatible string the patch must be send to the DT
> maintainers and the devicetree mailing list otherwise they don't have any
> chance to review.
> 

Sure, my fault. I just used list of recipients from the initial patch.  

Regards,
Ivan