clk: Mark fwnodes when their clock provider is added
diff mbox series

Message ID 20210210114435.122242-2-tudor.ambarus@microchip.com
State New, archived
Headers show
Series
  • clk: Mark fwnodes when their clock provider is added
Related show

Commit Message

Tudor Ambarus Feb. 10, 2021, 11:44 a.m. UTC
This is a follow-up for:
commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")

The above commit updated the deprecated of_clk_add_provider(),
but missed to update the preferred of_clk_add_hw_provider().
Update it now.

Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
---
 drivers/clk/clk.c | 2 ++
 1 file changed, 2 insertions(+)

Comments

Greg Kroah-Hartman Feb. 11, 2021, 1 p.m. UTC | #1
On Wed, Feb 10, 2021 at 01:44:35PM +0200, Tudor Ambarus wrote:
> This is a follow-up for:
> commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> 
> The above commit updated the deprecated of_clk_add_provider(),
> but missed to update the preferred of_clk_add_hw_provider().
> Update it now.
> 
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> ---
>  drivers/clk/clk.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 27ff90eacb1f..9370e4dfecae 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -4594,6 +4594,8 @@ int of_clk_add_hw_provider(struct device_node *np,
>  	if (ret < 0)
>  		of_clk_del_provider(np);
>  
> +	fwnode_dev_initialized(&np->fwnode, true);
> +
>  	return ret;
>  }
>  EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);
> -- 
> 2.25.1
> 

Any objection for me taking this in my tree as well?

thanks,

greg k-h
Stephen Boyd Feb. 13, 2021, 12:37 a.m. UTC | #2
Quoting Greg KH (2021-02-11 05:00:51)
> On Wed, Feb 10, 2021 at 01:44:35PM +0200, Tudor Ambarus wrote:
> > This is a follow-up for:
> > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> > 
> > The above commit updated the deprecated of_clk_add_provider(),
> > but missed to update the preferred of_clk_add_hw_provider().
> > Update it now.
> > 
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > ---

Acked-by: Stephen Boyd <sboyd@kernel.org>
Marek Szyprowski March 25, 2021, 1:31 p.m. UTC | #3
Hi

On 10.02.2021 12:44, Tudor Ambarus wrote:
> This is a follow-up for:
> commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
>
> The above commit updated the deprecated of_clk_add_provider(),
> but missed to update the preferred of_clk_add_hw_provider().
> Update it now.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>

This patch, which landed in linux-next as commit 6579c8d97ad7 ("clk: 
Mark fwnodes when their clock provider is added") causes the following 
NULL pointer dereference on Raspberry Pi 3b+ boards:

--->8---

raspberrypi-firmware soc:firmware: Attached to firmware from 
2020-01-06T13:05:25
Unable to handle kernel NULL pointer dereference at virtual address 
0000000000000050
Mem abort info:
   ESR = 0x96000004
   EC = 0x25: DABT (current EL), IL = 32 bits
   SET = 0, FnV = 0
   EA = 0, S1PTW = 0
Data abort info:
   ISV = 0, ISS = 0x00000004
   CM = 0, WnR = 0
[0000000000000050] user address but active_mm is swapper
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 5.12.0-rc4+ #2764
Hardware name: Raspberry Pi 3 Model B (DT)
Workqueue: events deferred_probe_work_func
pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
pc : of_clk_add_hw_provider+0xac/0xe8
lr : of_clk_add_hw_provider+0x94/0xe8
sp : ffff8000130936b0
x29: ffff8000130936b0 x28: ffff800012494e04
x27: ffff00003b18cb05 x26: ffff00003aa5c010
x25: 0000000000000000 x24: 0000000000000000
x23: ffff00003aa1e380 x22: ffff8000106830d0
x21: ffff80001233f180 x20: 0000000000000018
x19: 0000000000000000 x18: ffff8000124d38b0
x17: 0000000000000013 x16: 0000000000000014
x15: ffff8000125758b0 x14: 00000000000184e0
x13: 000000000000292e x12: ffff80001258dd98
x11: 0000000000000001 x10: 0101010101010101
x9 : ffff80001233f288 x8 : 7f7f7f7f7f7f7f7f
x7 : fefefefeff6c626f x6 : 5d636d8080808080
x5 : 00000000006d635d x4 : 0000000000000000
x3 : 0000000000000000 x2 : 540eb5edae191600
x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
  of_clk_add_hw_provider+0xac/0xe8
  devm_of_clk_add_hw_provider+0x5c/0xb8
  raspberrypi_clk_probe+0x110/0x210
  platform_probe+0x90/0xd8
  really_probe+0x108/0x3c0
  driver_probe_device+0x60/0xc0
  __device_attach_driver+0x9c/0xd0
  bus_for_each_drv+0x70/0xc8
  __device_attach+0xec/0x150
  device_initial_probe+0x10/0x18
  bus_probe_device+0x94/0xa0
  device_add+0x47c/0x780
  platform_device_add+0x110/0x248
  platform_device_register_full+0x120/0x150
  rpi_firmware_probe+0x158/0x1f8
  platform_probe+0x90/0xd8
  really_probe+0x108/0x3c0
  driver_probe_device+0x60/0xc0
  __device_attach_driver+0x9c/0xd0
  bus_for_each_drv+0x70/0xc8
  __device_attach+0xec/0x150
  device_initial_probe+0x10/0x18
  bus_probe_device+0x94/0xa0
  deferred_probe_work_func+0x70/0xa8
  process_one_work+0x2a8/0x718
  worker_thread+0x48/0x460
  kthread+0x134/0x160
  ret_from_fork+0x10/0x18
Code: b1006294 540000c0 b140069f 54000088 (3940e280)
---[ end trace 7ead5ec2f0c51cfe ]---

This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls 
devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL 
dev->of_node. I'm not sure if adding a check for a NULL np in 
of_clk_add_hw_provider() is a right fix, though.

> ---
>   drivers/clk/clk.c | 2 ++
>   1 file changed, 2 insertions(+)
>
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 27ff90eacb1f..9370e4dfecae 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -4594,6 +4594,8 @@ int of_clk_add_hw_provider(struct device_node *np,
>   	if (ret < 0)
>   		of_clk_del_provider(np);
>   
> +	fwnode_dev_initialized(&np->fwnode, true);
> +
>   	return ret;
>   }
>   EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);

Best regards
Geert Uytterhoeven March 25, 2021, 3:47 p.m. UTC | #4
Hi Marek,

On Thu, Mar 25, 2021 at 2:32 PM Marek Szyprowski
<m.szyprowski@samsung.com> wrote:
> On 10.02.2021 12:44, Tudor Ambarus wrote:
> > This is a follow-up for:
> > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> >
> > The above commit updated the deprecated of_clk_add_provider(),
> > but missed to update the preferred of_clk_add_hw_provider().
> > Update it now.
> >
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
>
> This patch, which landed in linux-next as commit 6579c8d97ad7 ("clk:
> Mark fwnodes when their clock provider is added") causes the following
> NULL pointer dereference on Raspberry Pi 3b+ boards:
>
> --->8---
>
> raspberrypi-firmware soc:firmware: Attached to firmware from
> 2020-01-06T13:05:25
> Unable to handle kernel NULL pointer dereference at virtual address
> 0000000000000050
> Mem abort info:
>    ESR = 0x96000004
>    EC = 0x25: DABT (current EL), IL = 32 bits
>    SET = 0, FnV = 0
>    EA = 0, S1PTW = 0
> Data abort info:
>    ISV = 0, ISS = 0x00000004
>    CM = 0, WnR = 0
> [0000000000000050] user address but active_mm is swapper
> Internal error: Oops: 96000004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 5.12.0-rc4+ #2764
> Hardware name: Raspberry Pi 3 Model B (DT)
> Workqueue: events deferred_probe_work_func
> pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
> pc : of_clk_add_hw_provider+0xac/0xe8
> lr : of_clk_add_hw_provider+0x94/0xe8
> sp : ffff8000130936b0
> x29: ffff8000130936b0 x28: ffff800012494e04
> x27: ffff00003b18cb05 x26: ffff00003aa5c010
> x25: 0000000000000000 x24: 0000000000000000
> x23: ffff00003aa1e380 x22: ffff8000106830d0
> x21: ffff80001233f180 x20: 0000000000000018
> x19: 0000000000000000 x18: ffff8000124d38b0
> x17: 0000000000000013 x16: 0000000000000014
> x15: ffff8000125758b0 x14: 00000000000184e0
> x13: 000000000000292e x12: ffff80001258dd98
> x11: 0000000000000001 x10: 0101010101010101
> x9 : ffff80001233f288 x8 : 7f7f7f7f7f7f7f7f
> x7 : fefefefeff6c626f x6 : 5d636d8080808080
> x5 : 00000000006d635d x4 : 0000000000000000
> x3 : 0000000000000000 x2 : 540eb5edae191600
> x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
>   of_clk_add_hw_provider+0xac/0xe8
>   devm_of_clk_add_hw_provider+0x5c/0xb8
>   raspberrypi_clk_probe+0x110/0x210
>   platform_probe+0x90/0xd8
>   really_probe+0x108/0x3c0
>   driver_probe_device+0x60/0xc0
>   __device_attach_driver+0x9c/0xd0
>   bus_for_each_drv+0x70/0xc8
>   __device_attach+0xec/0x150
>   device_initial_probe+0x10/0x18
>   bus_probe_device+0x94/0xa0
>   device_add+0x47c/0x780
>   platform_device_add+0x110/0x248
>   platform_device_register_full+0x120/0x150
>   rpi_firmware_probe+0x158/0x1f8

> This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls
> devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL
> dev->of_node. I'm not sure if adding a check for a NULL np in
> of_clk_add_hw_provider() is a right fix, though.

raspberrypi_clk_probe():

        /*
         * We can be probed either through the an old-fashioned
         * platform device registration or through a DT node that is a
         * child of the firmware node. Handle both cases.
         */

So the real issue is rpi_register_clk_driver() creating a platform
device for the firmware clocks if they're missing in DT.

Then, the clock driver calls devm_of_clk_add_hw_provider(),
regardless of a DT node being present or not.
I'm wondering how power consumers are supposed to refer
to these firmware clocks, without a DT node?

> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -4594,6 +4594,8 @@ int of_clk_add_hw_provider(struct device_node *np,
> >       if (ret < 0)
> >               of_clk_del_provider(np);
> >
> > +     fwnode_dev_initialized(&np->fwnode, true);
> > +
> >       return ret;
> >   }
> >   EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);

Gr{oetje,eeting}s,

                        Geert
Nicolas Saenz Julienne March 25, 2021, 6:25 p.m. UTC | #5
On Thu, 2021-03-25 at 14:31 +0100, Marek Szyprowski wrote:
> Hi
> 
> On 10.02.2021 12:44, Tudor Ambarus wrote:
> > This is a follow-up for:
> > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> > 
> > The above commit updated the deprecated of_clk_add_provider(),
> > but missed to update the preferred of_clk_add_hw_provider().
> > Update it now.
> > 
> > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> 
> This patch, which landed in linux-next as commit 6579c8d97ad7 ("clk: 
> Mark fwnodes when their clock provider is added") causes the following 
> NULL pointer dereference on Raspberry Pi 3b+ boards:
> 
> --->8---
> 
> raspberrypi-firmware soc:firmware: Attached to firmware from 
> 2020-01-06T13:05:25
> Unable to handle kernel NULL pointer dereference at virtual address 
> 0000000000000050
> Mem abort info:
>    ESR = 0x96000004
>    EC = 0x25: DABT (current EL), IL = 32 bits
>    SET = 0, FnV = 0
>    EA = 0, S1PTW = 0
> Data abort info:
>    ISV = 0, ISS = 0x00000004
>    CM = 0, WnR = 0
> [0000000000000050] user address but active_mm is swapper
> Internal error: Oops: 96000004 [#1] PREEMPT SMP
> Modules linked in:
> CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 5.12.0-rc4+ #2764
> Hardware name: Raspberry Pi 3 Model B (DT)
> Workqueue: events deferred_probe_work_func
> pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
> pc : of_clk_add_hw_provider+0xac/0xe8
> lr : of_clk_add_hw_provider+0x94/0xe8
> sp : ffff8000130936b0
> x29: ffff8000130936b0 x28: ffff800012494e04
> x27: ffff00003b18cb05 x26: ffff00003aa5c010
> x25: 0000000000000000 x24: 0000000000000000
> x23: ffff00003aa1e380 x22: ffff8000106830d0
> x21: ffff80001233f180 x20: 0000000000000018
> x19: 0000000000000000 x18: ffff8000124d38b0
> x17: 0000000000000013 x16: 0000000000000014
> x15: ffff8000125758b0 x14: 00000000000184e0
> x13: 000000000000292e x12: ffff80001258dd98
> x11: 0000000000000001 x10: 0101010101010101
> x9 : ffff80001233f288 x8 : 7f7f7f7f7f7f7f7f
> x7 : fefefefeff6c626f x6 : 5d636d8080808080
> x5 : 00000000006d635d x4 : 0000000000000000
> x3 : 0000000000000000 x2 : 540eb5edae191600
> x1 : 0000000000000000 x0 : 0000000000000000
> Call trace:
>   of_clk_add_hw_provider+0xac/0xe8
>   devm_of_clk_add_hw_provider+0x5c/0xb8
>   raspberrypi_clk_probe+0x110/0x210
>   platform_probe+0x90/0xd8
>   really_probe+0x108/0x3c0
>   driver_probe_device+0x60/0xc0
>   __device_attach_driver+0x9c/0xd0
>   bus_for_each_drv+0x70/0xc8
>   __device_attach+0xec/0x150
>   device_initial_probe+0x10/0x18
>   bus_probe_device+0x94/0xa0
>   device_add+0x47c/0x780
>   platform_device_add+0x110/0x248
>   platform_device_register_full+0x120/0x150
>   rpi_firmware_probe+0x158/0x1f8
>   platform_probe+0x90/0xd8
>   really_probe+0x108/0x3c0
>   driver_probe_device+0x60/0xc0
>   __device_attach_driver+0x9c/0xd0
>   bus_for_each_drv+0x70/0xc8
>   __device_attach+0xec/0x150
>   device_initial_probe+0x10/0x18
>   bus_probe_device+0x94/0xa0
>   deferred_probe_work_func+0x70/0xa8
>   process_one_work+0x2a8/0x718
>   worker_thread+0x48/0x460
>   kthread+0x134/0x160
>   ret_from_fork+0x10/0x18
> Code: b1006294 540000c0 b140069f 54000088 (3940e280)
> ---[ end trace 7ead5ec2f0c51cfe ]---
> 
> This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls 
> devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL 
> dev->of_node. I'm not sure if adding a check for a NULL np in 
> of_clk_add_hw_provider() is a right fix, though.

I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
is used, and it's defined and queried later through
devm_clk_hw_register_clkdev().

@Marek, I don't mind taking care of it if it's OK with you.

Regards,
Nicolas
Stephen Boyd March 26, 2021, 6:13 p.m. UTC | #6
Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> On Thu, 2021-03-25 at 14:31 +0100, Marek Szyprowski wrote:
> > Hi
> > 
> > On 10.02.2021 12:44, Tudor Ambarus wrote:
> > > This is a follow-up for:
> > > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> > > 
> > > The above commit updated the deprecated of_clk_add_provider(),
> > > but missed to update the preferred of_clk_add_hw_provider().
> > > Update it now.
> > > 
> > > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > 
> > This patch, which landed in linux-next as commit 6579c8d97ad7 ("clk: 
> > Mark fwnodes when their clock provider is added") causes the following 
> > NULL pointer dereference on Raspberry Pi 3b+ boards:
> > 
> > --->8---
> > 
> > raspberrypi-firmware soc:firmware: Attached to firmware from 
> > 2020-01-06T13:05:25
> > Unable to handle kernel NULL pointer dereference at virtual address 
> > 0000000000000050
> > Mem abort info:
> >    ESR = 0x96000004
> >    EC = 0x25: DABT (current EL), IL = 32 bits
> >    SET = 0, FnV = 0
> >    EA = 0, S1PTW = 0
> > Data abort info:
> >    ISV = 0, ISS = 0x00000004
> >    CM = 0, WnR = 0
> > [0000000000000050] user address but active_mm is swapper
> > Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > Modules linked in:
> > CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 5.12.0-rc4+ #2764
> > Hardware name: Raspberry Pi 3 Model B (DT)
> > Workqueue: events deferred_probe_work_func
> > pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
> > pc : of_clk_add_hw_provider+0xac/0xe8
> > lr : of_clk_add_hw_provider+0x94/0xe8
> > sp : ffff8000130936b0
> > x29: ffff8000130936b0 x28: ffff800012494e04
> > x27: ffff00003b18cb05 x26: ffff00003aa5c010
> > x25: 0000000000000000 x24: 0000000000000000
> > x23: ffff00003aa1e380 x22: ffff8000106830d0
> > x21: ffff80001233f180 x20: 0000000000000018
> > x19: 0000000000000000 x18: ffff8000124d38b0
> > x17: 0000000000000013 x16: 0000000000000014
> > x15: ffff8000125758b0 x14: 00000000000184e0
> > x13: 000000000000292e x12: ffff80001258dd98
> > x11: 0000000000000001 x10: 0101010101010101
> > x9 : ffff80001233f288 x8 : 7f7f7f7f7f7f7f7f
> > x7 : fefefefeff6c626f x6 : 5d636d8080808080
> > x5 : 00000000006d635d x4 : 0000000000000000
> > x3 : 0000000000000000 x2 : 540eb5edae191600
> > x1 : 0000000000000000 x0 : 0000000000000000
> > Call trace:
> >   of_clk_add_hw_provider+0xac/0xe8
> >   devm_of_clk_add_hw_provider+0x5c/0xb8
> >   raspberrypi_clk_probe+0x110/0x210
> >   platform_probe+0x90/0xd8
> >   really_probe+0x108/0x3c0
> >   driver_probe_device+0x60/0xc0
> >   __device_attach_driver+0x9c/0xd0
> >   bus_for_each_drv+0x70/0xc8
> >   __device_attach+0xec/0x150
> >   device_initial_probe+0x10/0x18
> >   bus_probe_device+0x94/0xa0
> >   device_add+0x47c/0x780
> >   platform_device_add+0x110/0x248
> >   platform_device_register_full+0x120/0x150
> >   rpi_firmware_probe+0x158/0x1f8
> >   platform_probe+0x90/0xd8
> >   really_probe+0x108/0x3c0
> >   driver_probe_device+0x60/0xc0
> >   __device_attach_driver+0x9c/0xd0
> >   bus_for_each_drv+0x70/0xc8
> >   __device_attach+0xec/0x150
> >   device_initial_probe+0x10/0x18
> >   bus_probe_device+0x94/0xa0
> >   deferred_probe_work_func+0x70/0xa8
> >   process_one_work+0x2a8/0x718
> >   worker_thread+0x48/0x460
> >   kthread+0x134/0x160
> >   ret_from_fork+0x10/0x18
> > Code: b1006294 540000c0 b140069f 54000088 (3940e280)
> > ---[ end trace 7ead5ec2f0c51cfe ]---
> > 
> > This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls 
> > devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL 
> > dev->of_node. I'm not sure if adding a check for a NULL np in 
> > of_clk_add_hw_provider() is a right fix, though.
> 
> I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
> 'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
> is used, and it's defined and queried later through
> devm_clk_hw_register_clkdev().
> 
> @Marek, I don't mind taking care of it if it's OK with you.
> 

Ah I see this is related to the patch I just reviewed. Can you reference
this in the commit text? And instead of putting the change into the clk
provider let's check for NULL 'np' in of_clk_add_hw_provider() instead
and return 0 if there's nothing to do. That way we don't visit this
problem over and over again.
Geert Uytterhoeven March 26, 2021, 6:29 p.m. UTC | #7
Hi Stephen,

On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> > On Thu, 2021-03-25 at 14:31 +0100, Marek Szyprowski wrote:
> > > On 10.02.2021 12:44, Tudor Ambarus wrote:
> > > > This is a follow-up for:
> > > > commit 3c9ea42802a1 ("clk: Mark fwnodes when their clock provider is added/removed")
> > > >
> > > > The above commit updated the deprecated of_clk_add_provider(),
> > > > but missed to update the preferred of_clk_add_hw_provider().
> > > > Update it now.
> > > >
> > > > Signed-off-by: Tudor Ambarus <tudor.ambarus@microchip.com>
> > >
> > > This patch, which landed in linux-next as commit 6579c8d97ad7 ("clk:
> > > Mark fwnodes when their clock provider is added") causes the following
> > > NULL pointer dereference on Raspberry Pi 3b+ boards:
> > >
> > > --->8---
> > >
> > > raspberrypi-firmware soc:firmware: Attached to firmware from
> > > 2020-01-06T13:05:25
> > > Unable to handle kernel NULL pointer dereference at virtual address
> > > 0000000000000050
> > > Mem abort info:
> > >    ESR = 0x96000004
> > >    EC = 0x25: DABT (current EL), IL = 32 bits
> > >    SET = 0, FnV = 0
> > >    EA = 0, S1PTW = 0
> > > Data abort info:
> > >    ISV = 0, ISS = 0x00000004
> > >    CM = 0, WnR = 0
> > > [0000000000000050] user address but active_mm is swapper
> > > Internal error: Oops: 96000004 [#1] PREEMPT SMP
> > > Modules linked in:
> > > CPU: 0 PID: 10 Comm: kworker/0:1 Not tainted 5.12.0-rc4+ #2764
> > > Hardware name: Raspberry Pi 3 Model B (DT)
> > > Workqueue: events deferred_probe_work_func
> > > pstate: 00000005 (nzcv daif -PAN -UAO -TCO BTYPE=--)
> > > pc : of_clk_add_hw_provider+0xac/0xe8
> > > lr : of_clk_add_hw_provider+0x94/0xe8
> > > sp : ffff8000130936b0
> > > x29: ffff8000130936b0 x28: ffff800012494e04
> > > x27: ffff00003b18cb05 x26: ffff00003aa5c010
> > > x25: 0000000000000000 x24: 0000000000000000
> > > x23: ffff00003aa1e380 x22: ffff8000106830d0
> > > x21: ffff80001233f180 x20: 0000000000000018
> > > x19: 0000000000000000 x18: ffff8000124d38b0
> > > x17: 0000000000000013 x16: 0000000000000014
> > > x15: ffff8000125758b0 x14: 00000000000184e0
> > > x13: 000000000000292e x12: ffff80001258dd98
> > > x11: 0000000000000001 x10: 0101010101010101
> > > x9 : ffff80001233f288 x8 : 7f7f7f7f7f7f7f7f
> > > x7 : fefefefeff6c626f x6 : 5d636d8080808080
> > > x5 : 00000000006d635d x4 : 0000000000000000
> > > x3 : 0000000000000000 x2 : 540eb5edae191600
> > > x1 : 0000000000000000 x0 : 0000000000000000
> > > Call trace:
> > >   of_clk_add_hw_provider+0xac/0xe8
> > >   devm_of_clk_add_hw_provider+0x5c/0xb8
> > >   raspberrypi_clk_probe+0x110/0x210
> > >   platform_probe+0x90/0xd8
> > >   really_probe+0x108/0x3c0
> > >   driver_probe_device+0x60/0xc0
> > >   __device_attach_driver+0x9c/0xd0
> > >   bus_for_each_drv+0x70/0xc8
> > >   __device_attach+0xec/0x150
> > >   device_initial_probe+0x10/0x18
> > >   bus_probe_device+0x94/0xa0
> > >   device_add+0x47c/0x780
> > >   platform_device_add+0x110/0x248
> > >   platform_device_register_full+0x120/0x150
> > >   rpi_firmware_probe+0x158/0x1f8
> > >   platform_probe+0x90/0xd8
> > >   really_probe+0x108/0x3c0
> > >   driver_probe_device+0x60/0xc0
> > >   __device_attach_driver+0x9c/0xd0
> > >   bus_for_each_drv+0x70/0xc8
> > >   __device_attach+0xec/0x150
> > >   device_initial_probe+0x10/0x18
> > >   bus_probe_device+0x94/0xa0
> > >   deferred_probe_work_func+0x70/0xa8
> > >   process_one_work+0x2a8/0x718
> > >   worker_thread+0x48/0x460
> > >   kthread+0x134/0x160
> > >   ret_from_fork+0x10/0x18
> > > Code: b1006294 540000c0 b140069f 54000088 (3940e280)
> > > ---[ end trace 7ead5ec2f0c51cfe ]---
> > >
> > > This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls
> > > devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL
> > > dev->of_node. I'm not sure if adding a check for a NULL np in
> > > of_clk_add_hw_provider() is a right fix, though.
> >
> > I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
> > 'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
> > is used, and it's defined and queried later through
> > devm_clk_hw_register_clkdev().
> >
> > @Marek, I don't mind taking care of it if it's OK with you.
> >
>
> Ah I see this is related to the patch I just reviewed. Can you reference
> this in the commit text? And instead of putting the change into the clk
> provider let's check for NULL 'np' in of_clk_add_hw_provider() instead
> and return 0 if there's nothing to do. That way we don't visit this
> problem over and over again.

I'm not sure the latter is what we reall want: shouldn't calling
*of*_clk_add_hw_provider() with a NULL np be a bug in the provider?

Gr{oetje,eeting}s,

                        Geert
Saravana Kannan March 29, 2021, 11:28 p.m. UTC | #8
On Mon, Mar 29, 2021 at 2:25 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Geert Uytterhoeven (2021-03-26 11:29:55)
> > On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> > > > >
> > > > > This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls
> > > > > devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL
> > > > > dev->of_node. I'm not sure if adding a check for a NULL np in
> > > > > of_clk_add_hw_provider() is a right fix, though.
> > > >
> > > > I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
> > > > 'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
> > > > is used, and it's defined and queried later through
> > > > devm_clk_hw_register_clkdev().
> > > >
> > > > @Marek, I don't mind taking care of it if it's OK with you.
> > > >
> > >
> > > Ah I see this is related to the patch I just reviewed. Can you reference
> > > this in the commit text? And instead of putting the change into the clk
> > > provider let's check for NULL 'np' in of_clk_add_hw_provider() instead
> > > and return 0 if there's nothing to do. That way we don't visit this
> > > problem over and over again.
> >
> > I'm not sure the latter is what we reall want: shouldn't calling
> > *of*_clk_add_hw_provider() with a NULL np be a bug in the provider?
> >
>
> I don't have a strong opinion either way. Would it be useful if the
> function returned an error when 'np' is NULL?

I lean towards returning an error. Not a strong opinion either.

-Saravana

> I guess the caller could
> use that to figure out that it should register a clkdev. But it
> shouldn't hurt to register both a clkdev lookup and a DT provider for
> the same clk. The framework will try the DT path first and then fallback
> to a clkdev lookup otherwise, so we'll be wasting memory for clkdev but
> otherwise be fine.
>
> Really it feels like we should try to unify around a
> devm_clk_add_hw_provider() API that figures out what to do based on if
> the device has an of_node or not. That would mean implementing something
> like clkdev but for a whole provider instead of a single clk. Then this
> question of returning an error would be moot here.
Geert Uytterhoeven March 30, 2021, 6:58 a.m. UTC | #9
Hi Stephen,

On Tue, Mar 30, 2021 at 3:53 AM Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Saravana Kannan (2021-03-29 16:28:20)
> > On Mon, Mar 29, 2021 at 2:25 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > Quoting Geert Uytterhoeven (2021-03-26 11:29:55)
> > > > On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> > > > > > >
> > > > > > > This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls
> > > > > > > devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL
> > > > > > > dev->of_node. I'm not sure if adding a check for a NULL np in
> > > > > > > of_clk_add_hw_provider() is a right fix, though.
> > > > > >
> > > > > > I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
> > > > > > 'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
> > > > > > is used, and it's defined and queried later through
> > > > > > devm_clk_hw_register_clkdev().
> > > > > >
> > > > > > @Marek, I don't mind taking care of it if it's OK with you.
> > > > > >
> > > > >
> > > > > Ah I see this is related to the patch I just reviewed. Can you reference
> > > > > this in the commit text? And instead of putting the change into the clk
> > > > > provider let's check for NULL 'np' in of_clk_add_hw_provider() instead
> > > > > and return 0 if there's nothing to do. That way we don't visit this
> > > > > problem over and over again.
> > > >
> > > > I'm not sure the latter is what we reall want: shouldn't calling
> > > > *of*_clk_add_hw_provider() with a NULL np be a bug in the provider?
> > > >
> > >
> > > I don't have a strong opinion either way. Would it be useful if the
> > > function returned an error when 'np' is NULL?
> >
> > I lean towards returning an error. Not a strong opinion either.
>
> Does it have any use?

of_clk_del_provider() removes the first provider found with node == NULL.
If there are two drivers calling of_clk_add_hw_provider(), and one of
hem calls of_clk_del_provider() later, the wrong provider may be
removed from the list.

Gr{oetje,eeting}s,

                        Geert
Geert Uytterhoeven March 31, 2021, 7:05 a.m. UTC | #10
Hi Stephen,

On Wed, Mar 31, 2021 at 4:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> Quoting Geert Uytterhoeven (2021-03-29 23:58:23)
> > On Tue, Mar 30, 2021 at 3:53 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > > Quoting Saravana Kannan (2021-03-29 16:28:20)
> > > > On Mon, Mar 29, 2021 at 2:25 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > Quoting Geert Uytterhoeven (2021-03-26 11:29:55)
> > > > > > On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > > > Quoting Nicolas Saenz Julienne (2021-03-25 11:25:24)
> > > > > > > > >
> > > > > > > > > This patch mainly revealed that clk/bcm/clk-raspberrypi.c driver calls
> > > > > > > > > devm_of_clk_add_hw_provider(), with a device pointer, which has a NULL
> > > > > > > > > dev->of_node. I'm not sure if adding a check for a NULL np in
> > > > > > > > > of_clk_add_hw_provider() is a right fix, though.
> > > > > > > >
> > > > > > > > I believe the right fix is not to call 'devm_of_clk_add_hw_provider()' if
> > > > > > > > 'pdev->dev.of_node == NULL'. In such case, which is RPi3's, only the CPU clock
> > > > > > > > is used, and it's defined and queried later through
> > > > > > > > devm_clk_hw_register_clkdev().
> > > > > > > >
> > > > > > > > @Marek, I don't mind taking care of it if it's OK with you.
> > > > > > > >
> > > > > > >
> > > > > > > Ah I see this is related to the patch I just reviewed. Can you reference
> > > > > > > this in the commit text? And instead of putting the change into the clk
> > > > > > > provider let's check for NULL 'np' in of_clk_add_hw_provider() instead
> > > > > > > and return 0 if there's nothing to do. That way we don't visit this
> > > > > > > problem over and over again.
> > > > > >
> > > > > > I'm not sure the latter is what we reall want: shouldn't calling
> > > > > > *of*_clk_add_hw_provider() with a NULL np be a bug in the provider?
> > > > > >
> > > > >
> > > > > I don't have a strong opinion either way. Would it be useful if the
> > > > > function returned an error when 'np' is NULL?
> > > >
> > > > I lean towards returning an error. Not a strong opinion either.
> > >
> > > Does it have any use?
> >
> > of_clk_del_provider() removes the first provider found with node == NULL.
> > If there are two drivers calling of_clk_add_hw_provider(), and one of
> > hem calls of_clk_del_provider() later, the wrong provider may be
> > removed from the list.
> >
>
> So you're saying we shouldn't add a NULL device node pointer to the list
> so that this can't happen? That doesn't mean returning an error from
> of_clk_add_hw_provider() would be useful though.
> of_clk_add_hw_provider() can return 0 if np == NULL and
> of_clk_del_provider() can return early if np == NULL too.

I don't know if I grasp all meanings of the above.

The main question is if it is valid for a driver to call
of_clk_add_hw_provider()
with np == NULL.
  - If yes, should that register the provider?
      - If yes, how to handle two drivers calling of_clk_add_hw_provider()
        with np = NULL, as their unregistration order is not guaranteed to
        be correct.

If no, is that something to ignore (0), or a bug (error)?

Gr{oetje,eeting}s,

                        Geert
Nicolas Saenz Julienne April 5, 2021, 11:04 a.m. UTC | #11
On Wed, 2021-03-31 at 12:25 -0700, Stephen Boyd wrote:
> Quoting Geert Uytterhoeven (2021-03-31 00:05:00)
> > On Wed, Mar 31, 2021 at 4:22 AM Stephen Boyd <sboyd@kernel.org> wrote:
> > > > > Does it have any use?
> > > > 
> > > > of_clk_del_provider() removes the first provider found with node == NULL.
> > > > If there are two drivers calling of_clk_add_hw_provider(), and one of
> > > > hem calls of_clk_del_provider() later, the wrong provider may be
> > > > removed from the list.
> > > > 
> > > 
> > > So you're saying we shouldn't add a NULL device node pointer to the list
> > > so that this can't happen? That doesn't mean returning an error from
> > > of_clk_add_hw_provider() would be useful though.
> > > of_clk_add_hw_provider() can return 0 if np == NULL and
> > > of_clk_del_provider() can return early if np == NULL too.
> > 
> > I don't know if I grasp all meanings of the above.
> > 
> > The main question is if it is valid for a driver to call
> > of_clk_add_hw_provider()
> > with np == NULL.
> >   - If yes, should that register the provider?
> 
> No it should not register the provider. That would be bad as you pointed
> out.
> 
> >       - If yes, how to handle two drivers calling of_clk_add_hw_provider()
> >         with np = NULL, as their unregistration order is not guaranteed to
> >         be correct.
> > 
> > If no, is that something to ignore (0), or a bug (error)?
> 
> This is my question above. Is there a use to having
> of_clk_add_hw_provider() return an error value when np == NULL? I doubt
> it.
> 
> Returning 0 would reduce the if conditions in driver code in this case
> and be consistent with the CONFIG_OF=n inline stub that returns 0 when
> CONFIG_OF is disabled. The only case an error would be returned is if we
> couldn't allocate memory or if the assigned clocks code failed. Seems
> sane to me. The downside is that drivers would maybe register clkdev
> lookups when they don't need to and waste some memory. I'm fine with
> that until we have some sort of non-DT based clk provider lookup
> mechanism that could unify the two methods.

What about devm_of_clk_add_hw_provider() users, do we care that a seemingly
empty managed resource will be created?

Regards,
Nicolas

Patch
diff mbox series

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 27ff90eacb1f..9370e4dfecae 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -4594,6 +4594,8 @@  int of_clk_add_hw_provider(struct device_node *np,
 	if (ret < 0)
 		of_clk_del_provider(np);
 
+	fwnode_dev_initialized(&np->fwnode, true);
+
 	return ret;
 }
 EXPORT_SYMBOL_GPL(of_clk_add_hw_provider);