From iivanov at suse.de  Tue Apr 11 06:50:35 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Tue, 11 Apr 2023 16:50:35 +0300
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
Message-ID: <20230411135035.106725-1-iivanov@suse.de>

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

Signed-off-by: Ivan T. Ivanov <iivanov at suse.de>
---
 drivers/nvmem/rmem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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



From stefan.wahren at i2se.com  Tue Apr 11 09:53:38 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Tue, 11 Apr 2023 18:53:38 +0200
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <20230411135035.106725-1-iivanov@suse.de>
References: <20230411135035.106725-1-iivanov@suse.de>
Message-ID: <437e9983-55e9-3f9d-a94b-c746922973da@i2se.com>

Hi Ivan,

Am 11.04.23 um 15:50 schrieb 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'

could you please provide more background information:

- are two instances of rmem trying to create this file?
- which exact platform is affect (Raspberry Pi 4), because the Hardware 
name from the trace is useless?
- could you provide some reliable scenario/config to reproduce this issue?

> [    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
> 
> Signed-off-by: Ivan T. Ivanov <iivanov at suse.de>
> ---
>   drivers/nvmem/rmem.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nvmem/rmem.c b/drivers/nvmem/rmem.c
> index 80cb187f1481..77c70a47d519 100644
> --- a/drivers/nvmem/rmem.c
> +++ b/drivers/nvmem/rmem.c
> @@ -70,7 +70,7 @@ static int rmem_probe(struct platform_device *pdev)
>   
>   	config.dev = dev;
>   	config.priv = priv;
> -	config.name = "rmem";
> +	config.name = dev_name(dev);

AFAIR changing userspace isn't great because application could rely on 
the filename prefix.

What is the result after applying this patch:

ls bus/nvmem/devices/rmem*

>   	config.size = mem->size;
>   	config.reg_read = rmem_read;
>   


From srinivas.kandagatla at linaro.org  Tue Apr 11 09:56:23 2023
From: srinivas.kandagatla at linaro.org (Srinivas Kandagatla)
Date: Tue, 11 Apr 2023 17:56:23 +0100
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <20230411135035.106725-1-iivanov@suse.de>
References: <20230411135035.106725-1-iivanov@suse.de>
Message-ID: <c1943fbf-46fc-b20a-1351-a7328188aab0@linaro.org>



On 11/04/2023 14:50, Ivan T. Ivanov wrote:
> 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'

Have you considered using NVMEM_DEVID_AUTO?

--srini

> [    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
> 
> Signed-off-by: Ivan T. Ivanov <iivanov at suse.de>
> ---
>   drivers/nvmem/rmem.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/nvmem/rmem.c b/drivers/nvmem/rmem.c
> index 80cb187f1481..77c70a47d519 100644
> --- a/drivers/nvmem/rmem.c
> +++ b/drivers/nvmem/rmem.c
> @@ -70,7 +70,7 @@ static int rmem_probe(struct platform_device *pdev)
>   
>   	config.dev = dev;
>   	config.priv = priv;
> -	config.name = "rmem";
> +	config.name = dev_name(dev);
>   	config.size = mem->size;
>   	config.reg_read = rmem_read;
>   


From iivanov at suse.de  Wed Apr 12 00:08:04 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Wed, 12 Apr 2023 10:08:04 +0300
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <c1943fbf-46fc-b20a-1351-a7328188aab0@linaro.org>
References: <20230411135035.106725-1-iivanov@suse.de>
 <c1943fbf-46fc-b20a-1351-a7328188aab0@linaro.org>
Message-ID: <fojltyl6pkx6dkidb55lwtvygr4qz4f7k7fxw2m72i4r2kqmqy@fzz4pcg2jr25>

Hi Srini,

On 04-11 17:56, Srinivas Kandagatla wrote:
> 
> On 11/04/2023 14:50, Ivan T. Ivanov wrote:
> > 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'
> 
> Have you considered using NVMEM_DEVID_AUTO?

Thanks,  I missed this one. I will rework it and resend.

Regards,
Ivan



From iivanov at suse.de  Wed Apr 12 00:26:16 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Wed, 12 Apr 2023 10:26:16 +0300
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <437e9983-55e9-3f9d-a94b-c746922973da@i2se.com>
References: <20230411135035.106725-1-iivanov@suse.de>
 <437e9983-55e9-3f9d-a94b-c746922973da@i2se.com>
Message-ID: <r3x3b6fyejqg3ftcgigdrevsnlhbfrae2gztejsa3cnduaebf4@z3reu7bj6b6n>

Hi Stefan,

On 04-11 18:53, Stefan Wahren wrote:
> 
> Am 11.04.23 um 15:50 schrieb 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'
> 
> could you please provide more background information:
> 
> - are two instances of rmem trying to create this file?
> - which exact platform is affect (Raspberry Pi 4), because the Hardware name
> from the trace is useless?
> - could you provide some reliable scenario/config to reproduce this issue?

I was sure your will be asking. :-)

I am using RPi4[0] for testing this. Device tree is based on sources
from here [1]. From this devicetree it is  obvious what is happening.

Unfortunately right now SUSE Bugzilla is under maintenance, so perhaps you
can't see the bug report [2]. In brief I am using latest Tumbleweed on this
device and you can imagine that error is happening always.

Regards,
Ivan

[0] Raspberry Pi 4 Model B Rev 1.1
[1] https://github.com/raspberrypi/linux/blob/rpi-6.2.y/arch/arm/boot/dts/bcm2711-rpi.dtsi#L57
[2] https://bugzilla.suse.com/show_bug.cgi?id=1206846


From stefan.wahren at i2se.com  Wed Apr 12 08:10:41 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Wed, 12 Apr 2023 17:10:41 +0200
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <r3x3b6fyejqg3ftcgigdrevsnlhbfrae2gztejsa3cnduaebf4@z3reu7bj6b6n>
References: <20230411135035.106725-1-iivanov@suse.de>
 <437e9983-55e9-3f9d-a94b-c746922973da@i2se.com>
 <r3x3b6fyejqg3ftcgigdrevsnlhbfrae2gztejsa3cnduaebf4@z3reu7bj6b6n>
Message-ID: <43effe7f-9b2f-52d7-2570-decf2940a58c@i2se.com>

Am 12.04.23 um 09:26 schrieb Ivan T. Ivanov:
> Hi Stefan,
> 
> On 04-11 18:53, Stefan Wahren wrote:
>>
>> Am 11.04.23 um 15:50 schrieb 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'
>>
>> could you please provide more background information:
>>
>> - are two instances of rmem trying to create this file?
>> - which exact platform is affect (Raspberry Pi 4), because the Hardware name
>> from the trace is useless?
>> - could you provide some reliable scenario/config to reproduce this issue?
> 
> I was sure your will be asking. :-)
> 
> I am using RPi4[0] for testing this. Device tree is based on sources
> from here [1]. From this devicetree it is  obvious what is happening.

Thanks for clarifying. Unfortunately this file is not identical to the 
mainline file, so the issue can only be triggered with the vendor DTB?

> 
> Unfortunately right now SUSE Bugzilla is under maintenance, so perhaps you
> can't see the bug report [2]. In brief I am using latest Tumbleweed on this
> device and you can imagine that error is happening always.
> 
> Regards,
> Ivan
> 
> [0] Raspberry Pi 4 Model B Rev 1.1
> [1] https://github.com/raspberrypi/linux/blob/rpi-6.2.y/arch/arm/boot/dts/bcm2711-rpi.dtsi#L57
> [2] https://bugzilla.suse.com/show_bug.cgi?id=1206846


From iivanov at suse.de  Thu Apr 13 00:33:03 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Thu, 13 Apr 2023 10:33:03 +0300
Subject: [PATCH] nvmem: rmem: Make reserved region name unique
In-Reply-To: <43effe7f-9b2f-52d7-2570-decf2940a58c@i2se.com>
References: <20230411135035.106725-1-iivanov@suse.de>
 <437e9983-55e9-3f9d-a94b-c746922973da@i2se.com>
 <r3x3b6fyejqg3ftcgigdrevsnlhbfrae2gztejsa3cnduaebf4@z3reu7bj6b6n>
 <43effe7f-9b2f-52d7-2570-decf2940a58c@i2se.com>
Message-ID: <btjh6exqa5tzxjcqtayyemgm6lyh3cktcqgnd7ofqgtlu2sylp@jm5tcggnvo3z>

Hi,

On 04-12 17:10, Stefan Wahren wrote:
> > 
> > I am using RPi4[0] for testing this. Device tree is based on sources
> > from here [1]. From this devicetree it is  obvious what is happening.
> 
> Thanks for clarifying. Unfortunately this file is not identical to the
> mainline file, so the issue can only be triggered with the vendor DTB?
> 

Patch which adds this here [4] is coming ...

Regards,
Ivan

> > [0] Raspberry Pi 4 Model B Rev 1.1
> > [1] https://github.com/raspberrypi/linux/blob/rpi-6.2.y/arch/arm/boot/dts/bcm2711-rpi.dtsi#L57
> > [2] https://bugzilla.suse.com/show_bug.cgi?id=1206846

[4] https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/bcm2711-rpi.dtsi#L56


From iivanov at suse.de  Thu Apr 13 01:52:06 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Thu, 13 Apr 2023 11:52:06 +0300
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader public key
In-Reply-To: <20230413085206.149730-1-iivanov@suse.de>
References: <20230413085206.149730-1-iivanov@suse.de>
Message-ID: <20230413085206.149730-3-iivanov@suse.de>

From: Tim Gover <tim.gover at 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 at raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov at 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 at 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 at 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



From iivanov at suse.de  Thu Apr 13 01:52:05 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Thu, 13 Apr 2023 11:52:05 +0300
Subject: [PATCH v2 1/2] nvmem: rmem: Use NVMEM_DEVID_AUTO
In-Reply-To: <20230413085206.149730-1-iivanov@suse.de>
References: <20230413085206.149730-1-iivanov@suse.de>
Message-ID: <20230413085206.149730-2-iivanov@suse.de>

From: Phil Elwell <phil at 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 at raspberrypi.com>
Signed-off-by: Ivan T. Ivanov <iivanov at 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



From iivanov at suse.de  Thu Apr 13 01:52:04 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Thu, 13 Apr 2023 11:52:04 +0300
Subject: [PATCH v2 0/2] nvmem: rmem: Make reserved region name unique
Message-ID: <20230413085206.149730-1-iivanov@suse.de>

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



From stefan.wahren at i2se.com  Thu Apr 13 09:15:16 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 13 Apr 2023 18:15:16 +0200
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <20230413085206.149730-3-iivanov@suse.de>
References: <20230413085206.149730-1-iivanov@suse.de>
 <20230413085206.149730-3-iivanov@suse.de>
Message-ID: <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>

Hi Ivan,

Am 13.04.23 um 10:52 schrieb Ivan T. Ivanov:
> From: Tim Gover <tim.gover at 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 at raspberrypi.com>
> Signed-off-by: Ivan T. Ivanov <iivanov at 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 at 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 at 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 {


From iivanov at suse.de  Thu Apr 13 11:18:30 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Thu, 13 Apr 2023 21:18:30 +0300
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>
References: <20230413085206.149730-1-iivanov@suse.de>
 <20230413085206.149730-3-iivanov@suse.de>
 <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>
Message-ID: <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>

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 at 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 at 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



From stefan.wahren at i2se.com  Thu Apr 13 11:44:26 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 13 Apr 2023 20:44:26 +0200
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>
References: <20230413085206.149730-1-iivanov@suse.de>
 <20230413085206.149730-3-iivanov@suse.de>
 <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>
 <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>
Message-ID: <9de62851-73a6-0070-4e64-94b6614c11fd@i2se.com>

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 at 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 at 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
> 


From tim.gover at raspberrypi.com  Thu Apr 13 12:28:43 2023
From: tim.gover at raspberrypi.com (Tim Gover)
Date: Thu, 13 Apr 2023 20:28:43 +0100
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <9de62851-73a6-0070-4e64-94b6614c11fd@i2se.com>
References: <20230413085206.149730-1-iivanov@suse.de> <20230413085206.149730-3-iivanov@suse.de>
 <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com> <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>
 <9de62851-73a6-0070-4e64-94b6614c11fd@i2se.com>
Message-ID: <CAAvKZ64KyXJ2QPjRnj3i-8AKh7jGCUw=HNi76XG-a9K-+_JiYQ@mail.gmail.com>

On Thu, 13 Apr 2023 at 19:44, Stefan Wahren <stefan.wahren at 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 at 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 at 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


From stefan.wahren at i2se.com  Sun Apr 16 06:11:02 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Sun, 16 Apr 2023 15:11:02 +0200
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <CAAvKZ64KyXJ2QPjRnj3i-8AKh7jGCUw=HNi76XG-a9K-+_JiYQ@mail.gmail.com>
References: <20230413085206.149730-1-iivanov@suse.de>
 <20230413085206.149730-3-iivanov@suse.de>
 <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>
 <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>
 <9de62851-73a6-0070-4e64-94b6614c11fd@i2se.com>
 <CAAvKZ64KyXJ2QPjRnj3i-8AKh7jGCUw=HNi76XG-a9K-+_JiYQ@mail.gmail.com>
Message-ID: <02a4ebb4-7652-fb1f-ae56-920648470c67@i2se.com>

Hi,

Am 13.04.23 um 21:28 schrieb Tim Gover:
> On Thu, 13 Apr 2023 at 19:44, Stefan Wahren <stefan.wahren at 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 at 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 at 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


From mateusz.suchocki at stardalselva.pl  Tue Apr 18 01:33:08 2023
From: mateusz.suchocki at stardalselva.pl (Mateusz Suchocki)
Date: Tue, 18 Apr 2023 08:33:08 GMT
Subject: =?UTF-8?Q?Nawi=C4=85zanie_wsp=C3=B3=C5=82pracy?=
Message-ID: <20230418102739-0.1.7.rnk.0.cl257fcao9@stardalselva.pl>

Szanowni Pa?stwo,

Firma, kt?r? mam przyjemno?? reprezentowa? od 8 lat zajmuje si? wsparciem dzia?a? sprzeda?owych. Operujemy na styku marketingu i sprzeda?y inicjuj?c kontakt z wybran? przez partnera grup? docelow?, aby przekaza? do obs?ugi sprzeda?owej firmy zainteresowane dalszymi rozmowami, prezentacj? i ofert?.

Ka?dy z wypracowanych kontakt?w staje si? leadem dopiero po weryfikacji jego potencja?u przez zesp?? sprzeda?owy naszego partnera. Subiektywna ocena potencja?u na wsp??prac? jest podstaw? kwalifikacji leada.

Je?li w chwili obecnej stawiacie Pa?stwo na aktywne poszukiwanie klienta z mi?? ch?ci? podziel? si? wi?ksz? ilo?ci? szczeg???w.

Pozdrawiam
Mateusz Suchocki


From iivanov at suse.de  Tue Apr 18 01:49:09 2023
From: iivanov at suse.de (Ivan T. Ivanov)
Date: Tue, 18 Apr 2023 11:49:09 +0300
Subject: [PATCH v2 2/2] ARM: dts: Add nvmem node for BCM2711 bootloader
 public key
In-Reply-To: <02a4ebb4-7652-fb1f-ae56-920648470c67@i2se.com>
References: <20230413085206.149730-1-iivanov@suse.de>
 <20230413085206.149730-3-iivanov@suse.de>
 <9b03551a-278d-16dc-08ed-1ef0f89dc79c@i2se.com>
 <duuhz5pju4q7lnvzwndcnruqwqzbwy4jhrfn42vov2rfct4i7c@qh55cifhoud7>
 <9de62851-73a6-0070-4e64-94b6614c11fd@i2se.com>
 <CAAvKZ64KyXJ2QPjRnj3i-8AKh7jGCUw=HNi76XG-a9K-+_JiYQ@mail.gmail.com>
 <02a4ebb4-7652-fb1f-ae56-920648470c67@i2se.com>
Message-ID: <pdwhmblhzpo6dkpxs2d3p3vbmew2xivqspycezfngwigpf4doe@vgphotcelnsl>

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



From hverkuil at xs4all.nl  Wed Apr 19 23:47:31 2023
From: hverkuil at xs4all.nl (Hans Verkuil)
Date: Thu, 20 Apr 2023 08:47:31 +0200
Subject: [PATCH] pinctrl-bcm2835.c: fix race condition when setting gpio dir
Message-ID: <4c15982a-e159-4238-d484-3f2b3d7b39bd@xs4all.nl>

In the past setting the pin direction called pinctrl_gpio_direction()
which uses a mutex to serialize this. That was changed to set the
direction directly in the pin controller driver, but that lost the
serialization mechanism. Since the direction of multiple pins are in
the same register you can have a race condition, something that was
in fact observed with the cec-gpio driver.

Add a new spinlock to serialize writing to the FSEL registers.

Signed-off-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
Fixes: 1a4541b68e25 ("pinctrl-bcm2835: don't call pinctrl_gpio_direction()")
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 8e2551a08c37..345b9dea5ff6 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -90,6 +90,8 @@ struct bcm2835_pinctrl {
 	struct pinctrl_gpio_range gpio_range;

 	raw_spinlock_t irq_lock[BCM2835_NUM_BANKS];
+	/* Protect FSEL registers */
+	spinlock_t fsel_lock;
 };

 /* pins are just named GPIO0..GPIO53 */
@@ -284,14 +286,21 @@ static inline void bcm2835_pinctrl_fsel_set(
 		struct bcm2835_pinctrl *pc, unsigned pin,
 		enum bcm2835_fsel fsel)
 {
-	u32 val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
-	enum bcm2835_fsel cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;
+	u32 val;
+	enum bcm2835_fsel cur;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pc->fsel_lock, flags);
+	val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
+	cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;

 	dev_dbg(pc->dev, "read %08x (%u => %s)\n", val, pin,
-			bcm2835_functions[cur]);
+		bcm2835_functions[cur]);

-	if (cur == fsel)
+	if (cur == fsel) {
+		spin_unlock_irqrestore(&pc->fsel_lock, flags);
 		return;
+	}

 	if (cur != BCM2835_FSEL_GPIO_IN && fsel != BCM2835_FSEL_GPIO_IN) {
 		/* always transition through GPIO_IN */
@@ -309,6 +318,7 @@ static inline void bcm2835_pinctrl_fsel_set(
 	dev_dbg(pc->dev, "write %08x (%u <= %s)\n", val, pin,
 			bcm2835_functions[fsel]);
 	bcm2835_gpio_wr(pc, FSEL_REG(pin), val);
+	spin_unlock_irqrestore(&pc->fsel_lock, flags);
 }

 static int bcm2835_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
@@ -1248,6 +1258,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
 	pc->gpio_chip = *pdata->gpio_chip;
 	pc->gpio_chip.parent = dev;

+	spin_lock_init(&pc->fsel_lock);
 	for (i = 0; i < BCM2835_NUM_BANKS; i++) {
 		unsigned long events;
 		unsigned offset;
-- 
2.39.2



From kamil.tralewski at craftsplex.pl  Thu Apr 20 01:05:42 2023
From: kamil.tralewski at craftsplex.pl (Kamil Tralewski)
Date: Thu, 20 Apr 2023 08:05:42 GMT
Subject: =?UTF-8?Q?S=C5=82owa_kluczowe_do_wypozycjonowania?=
Message-ID: <20230420064500-0.1.5o.q95q.0.b4vg0ia7cv@craftsplex.pl>

Dzie? dobry,

zapozna?em si? z Pa?stwa ofert? i z przyjemno?ci? przyznaj?, ?e przyci?ga uwag? i zach?ca do dalszych rozm?w. 

Pomy?la?em, ?e mo?e m?g?bym mie? sw?j wk?ad w Pa?stwa rozw?j i pom?c dotrze? z t? ofert? do wi?kszego grona odbiorc?w. Pozycjonuj? strony www, dzi?ki czemu generuj? ?wietny ruch w sieci.

Mo?emy porozmawia? w najbli?szym czasie?

Pozdrawiam
Kamil Tralewski


From stefan.wahren at i2se.com  Thu Apr 20 03:34:42 2023
From: stefan.wahren at i2se.com (Stefan Wahren)
Date: Thu, 20 Apr 2023 12:34:42 +0200
Subject: [PATCH] pinctrl-bcm2835.c: fix race condition when setting gpio
 dir
In-Reply-To: <4c15982a-e159-4238-d484-3f2b3d7b39bd@xs4all.nl>
References: <4c15982a-e159-4238-d484-3f2b3d7b39bd@xs4all.nl>
Message-ID: <c13b29fc-ebad-7898-a03e-e028e6651810@i2se.com>

Hi Hans,

Am 20.04.23 um 08:47 schrieb Hans Verkuil:
> In the past setting the pin direction called pinctrl_gpio_direction()
> which uses a mutex to serialize this. That was changed to set the
> direction directly in the pin controller driver, but that lost the
> serialization mechanism. Since the direction of multiple pins are in
> the same register you can have a race condition, something that was
> in fact observed with the cec-gpio driver.
> 
> Add a new spinlock to serialize writing to the FSEL registers.
> 
> Signed-off-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
> Fixes: 1a4541b68e25 ("pinctrl-bcm2835: don't call pinctrl_gpio_direction()")
> ---
>   drivers/pinctrl/bcm/pinctrl-bcm2835.c | 19 +++++++++++++++----
>   1 file changed, 15 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> index 8e2551a08c37..345b9dea5ff6 100644
> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
> @@ -90,6 +90,8 @@ struct bcm2835_pinctrl {
>   	struct pinctrl_gpio_range gpio_range;
> 
>   	raw_spinlock_t irq_lock[BCM2835_NUM_BANKS];
> +	/* Protect FSEL registers */
> +	spinlock_t fsel_lock;
>   };
> 
>   /* pins are just named GPIO0..GPIO53 */
> @@ -284,14 +286,21 @@ static inline void bcm2835_pinctrl_fsel_set(
>   		struct bcm2835_pinctrl *pc, unsigned pin,
>   		enum bcm2835_fsel fsel)
>   {
> -	u32 val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
> -	enum bcm2835_fsel cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;
> +	u32 val;
> +	enum bcm2835_fsel cur;
> +	unsigned long flags;
> +
> +	spin_lock_irqsave(&pc->fsel_lock, flags);
> +	val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
> +	cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;
> 
>   	dev_dbg(pc->dev, "read %08x (%u => %s)\n", val, pin,
> -			bcm2835_functions[cur]);
> +		bcm2835_functions[cur]);
> 
> -	if (cur == fsel)
> +	if (cur == fsel) {
> +		spin_unlock_irqrestore(&pc->fsel_lock, flags);
>   		return;

How about adding a jump label to the latter spin_unlock_irqrestore and 
using a goto here?

> +	}
> 
>   	if (cur != BCM2835_FSEL_GPIO_IN && fsel != BCM2835_FSEL_GPIO_IN) {
>   		/* always transition through GPIO_IN */
> @@ -309,6 +318,7 @@ static inline void bcm2835_pinctrl_fsel_set(
>   	dev_dbg(pc->dev, "write %08x (%u <= %s)\n", val, pin,
>   			bcm2835_functions[fsel]);
>   	bcm2835_gpio_wr(pc, FSEL_REG(pin), val);
> +	spin_unlock_irqrestore(&pc->fsel_lock, flags);
>   }
> 
>   static int bcm2835_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
> @@ -1248,6 +1258,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
>   	pc->gpio_chip = *pdata->gpio_chip;
>   	pc->gpio_chip.parent = dev;
> 
> +	spin_lock_init(&pc->fsel_lock);
>   	for (i = 0; i < BCM2835_NUM_BANKS; i++) {
>   		unsigned long events;
>   		unsigned offset;


From hverkuil-cisco at xs4all.nl  Thu Apr 20 05:47:05 2023
From: hverkuil-cisco at xs4all.nl (Hans Verkuil)
Date: Thu, 20 Apr 2023 14:47:05 +0200
Subject: [PATCHv2] pinctrl-bcm2835.c: fix race condition when setting gpio dir
Message-ID: <4302b66b-ca20-0f19-d2aa-ee8661118863@xs4all.nl>

In the past setting the pin direction called pinctrl_gpio_direction()
which uses a mutex to serialize this. That was changed to set the
direction directly in the pin controller driver, but that lost the
serialization mechanism. Since the direction of multiple pins are in
the same register you can have a race condition, something that was
in fact observed with the cec-gpio driver.

Add a new spinlock to serialize writing to the FSEL registers.

Signed-off-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
Fixes: 1a4541b68e25 ("pinctrl-bcm2835: don't call pinctrl_gpio_direction()")
---
Changes since v1:
- use 'goto unlock' as per Stefan's suggestion
---
 drivers/pinctrl/bcm/pinctrl-bcm2835.c | 19 +++++++++++++++----
 1 file changed, 15 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
index 8e2551a08c37..7435173e10f4 100644
--- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
@@ -90,6 +90,8 @@ struct bcm2835_pinctrl {
 	struct pinctrl_gpio_range gpio_range;

 	raw_spinlock_t irq_lock[BCM2835_NUM_BANKS];
+	/* Protect FSEL registers */
+	spinlock_t fsel_lock;
 };

 /* pins are just named GPIO0..GPIO53 */
@@ -284,14 +286,19 @@ static inline void bcm2835_pinctrl_fsel_set(
 		struct bcm2835_pinctrl *pc, unsigned pin,
 		enum bcm2835_fsel fsel)
 {
-	u32 val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
-	enum bcm2835_fsel cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;
+	u32 val;
+	enum bcm2835_fsel cur;
+	unsigned long flags;
+
+	spin_lock_irqsave(&pc->fsel_lock, flags);
+	val = bcm2835_gpio_rd(pc, FSEL_REG(pin));
+	cur = (val >> FSEL_SHIFT(pin)) & BCM2835_FSEL_MASK;

 	dev_dbg(pc->dev, "read %08x (%u => %s)\n", val, pin,
-			bcm2835_functions[cur]);
+		bcm2835_functions[cur]);

 	if (cur == fsel)
-		return;
+		goto unlock;

 	if (cur != BCM2835_FSEL_GPIO_IN && fsel != BCM2835_FSEL_GPIO_IN) {
 		/* always transition through GPIO_IN */
@@ -309,6 +316,9 @@ static inline void bcm2835_pinctrl_fsel_set(
 	dev_dbg(pc->dev, "write %08x (%u <= %s)\n", val, pin,
 			bcm2835_functions[fsel]);
 	bcm2835_gpio_wr(pc, FSEL_REG(pin), val);
+
+unlock:
+	spin_unlock_irqrestore(&pc->fsel_lock, flags);
 }

 static int bcm2835_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
@@ -1248,6 +1258,7 @@ static int bcm2835_pinctrl_probe(struct platform_device *pdev)
 	pc->gpio_chip = *pdata->gpio_chip;
 	pc->gpio_chip.parent = dev;

+	spin_lock_init(&pc->fsel_lock);
 	for (i = 0; i < BCM2835_NUM_BANKS; i++) {
 		unsigned long events;
 		unsigned offset;
-- 
2.39.2



From linus.walleij at linaro.org  Fri Apr 21 02:01:39 2023
From: linus.walleij at linaro.org (Linus Walleij)
Date: Fri, 21 Apr 2023 11:01:39 +0200
Subject: [PATCHv2] pinctrl-bcm2835.c: fix race condition when setting gpio dir
In-Reply-To: <4302b66b-ca20-0f19-d2aa-ee8661118863@xs4all.nl>
References: <4302b66b-ca20-0f19-d2aa-ee8661118863@xs4all.nl>
Message-ID: <CACRpkdaorkV73hAEcnXHLV2WpGfPmnqnHy6mdo7=9wVGtH4zXA@mail.gmail.com>

On Thu, Apr 20, 2023 at 2:47?PM Hans Verkuil <hverkuil-cisco at xs4all.nl> wrote:

> In the past setting the pin direction called pinctrl_gpio_direction()
> which uses a mutex to serialize this. That was changed to set the
> direction directly in the pin controller driver, but that lost the
> serialization mechanism. Since the direction of multiple pins are in
> the same register you can have a race condition, something that was
> in fact observed with the cec-gpio driver.
>
> Add a new spinlock to serialize writing to the FSEL registers.
>
> Signed-off-by: Hans Verkuil <hverkuil-cisco at xs4all.nl>
> Fixes: 1a4541b68e25 ("pinctrl-bcm2835: don't call pinctrl_gpio_direction()")

I just applied this patch now so it can go in with the rest of the patches
for the merge window. I don't especially fancy having to immediately
start a fixes branch before I've even sent the bulk of patches to Torvalds.

Yours,
Linus Walleij


