| Message ID | 20210210114435.122242-2-tudor.ambarus@microchip.com (mailing list archive) |
|---|---|
| State | Awaiting Upstream, archived |
| Headers | show |
| Series | clk: Mark fwnodes when their clock provider is added | expand |
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
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>
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
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
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
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.
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
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.
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
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
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
Hi, 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> This patch still causes a crash when booting a raspi2 image in linux-next. [ 21.456500] Unable to handle kernel NULL pointer dereference at virtual address 00000028 [ 21.456750] pgd = (ptrval) [ 21.456927] [00000028] *pgd=00000000 [ 21.457567] Internal error: Oops: 5 [#1] SMP ARM [ 21.457882] Modules linked in: [ 21.458077] CPU: 0 PID: 77 Comm: kworker/u8:10 Not tainted 5.12.0-rc8-next-20210420 #1 [ 21.458291] Hardware name: BCM2835 [ 21.458525] Workqueue: events_unbound deferred_probe_work_func [ 21.458997] PC is at of_clk_add_hw_provider+0xbc/0xe8 [ 21.459176] LR is at of_clk_add_hw_provider+0xa8/0xe8 ... [ 21.477603] [<c0a32aec>] (of_clk_add_hw_provider) from [<c0a32b60>] (devm_of_clk_add_hw_provider+0x48/0x80) [ 21.477861] [<c0a32b60>] (devm_of_clk_add_hw_provider) from [<c0a471e4>] (raspberrypi_clk_probe+0x260/0x388) [ 21.478087] [<c0a471e4>] (raspberrypi_clk_probe) from [<c0c1c4d0>] (platform_probe+0x5c/0xb8) [ 21.478287] [<c0c1c4d0>] (platform_probe) from [<c0c19d84>] (really_probe+0xf0/0x39c) [ 21.478471] [<c0c19d84>] (really_probe) from [<c0c1a098>] (driver_probe_device+0x68/0xc0) [ 21.478659] [<c0c1a098>] (driver_probe_device) from [<c0c17f54>] (bus_for_each_drv+0x84/0xc8) [ 21.478860] [<c0c17f54>] (bus_for_each_drv) from [<c0c19c20>] (__device_attach+0xec/0x158) [ 21.479050] [<c0c19c20>] (__device_attach) from [<c0c18de8>] (bus_probe_device+0x88/0x90) [ 21.479236] [<c0c18de8>] (bus_probe_device) from [<c0c16a68>] (device_add+0x398/0x8ac) [ 21.479421] [<c0c16a68>] (device_add) from [<c0c1c1b4>] (platform_device_add+0xf0/0x200) [ 21.479607] [<c0c1c1b4>] (platform_device_add) from [<c0c1ccc0>] (platform_device_register_full+0xd0/0x110) [ 21.479836] [<c0c1ccc0>] (platform_device_register_full) from [<c104c130>] (rpi_firmware_probe+0x1a4/0x20c) [ 21.480061] [<c104c130>] (rpi_firmware_probe) from [<c0c1c4d0>] (platform_probe+0x5c/0xb8) [ 21.480255] [<c0c1c4d0>] (platform_probe) from [<c0c19d84>] (really_probe+0xf0/0x39c) [ 21.480437] [<c0c19d84>] (really_probe) from [<c0c1a098>] (driver_probe_device+0x68/0xc0) [ 21.480626] [<c0c1a098>] (driver_probe_device) from [<c0c17f54>] (bus_for_each_drv+0x84/0xc8) [ 21.480829] [<c0c17f54>] (bus_for_each_drv) from [<c0c19c20>] (__device_attach+0xec/0x158) [ 21.481018] [<c0c19c20>] (__device_attach) from [<c0c18de8>] (bus_probe_device+0x88/0x90) [ 21.481205] [<c0c18de8>] (bus_probe_device) from [<c0c192bc>] (deferred_probe_work_func+0x8c/0xbc) [ 21.481413] [<c0c192bc>] (deferred_probe_work_func) from [<c036802c>] (process_one_work+0x268/0x798) [ 21.481624] [<c036802c>] (process_one_work) from [<c0368774>] (worker_thread+0x218/0x4f4) [ 21.481822] [<c0368774>] (worker_thread) from [<c0370f28>] (kthread+0x140/0x174) [ 21.481999] [<c0370f28>] (kthread) from [<c030017c>] (ret_from_fork+0x14/0x38) [ 21.482185] Exception stack(0xc42b7fb0 to 0xc42b7ff8) Updated bisect log is attached. Guenter --- # bad: [50b8b1d699ac313c0a07a3c185ffb23aecab8abb] Add linux-next specific files for 20210419 # good: [bf05bf16c76bb44ab5156223e1e58e26dfe30a88] Linux 5.12-rc8 git bisect start 'HEAD' 'v5.12-rc8' # good: [c4bb91fc07e59241cde97f913d7a2fbedc248f0d] Merge remote-tracking branch 'crypto/master' git bisect good c4bb91fc07e59241cde97f913d7a2fbedc248f0d # good: [f15bbf170b40b48a43ed7076ce9f8ac9380e5752] Merge remote-tracking branch 'edac/edac-for-next' git bisect good f15bbf170b40b48a43ed7076ce9f8ac9380e5752 # bad: [550a78090dcc4061e191312a757a127f0b6e6323] Merge remote-tracking branch 'vfio/next' git bisect bad 550a78090dcc4061e191312a757a127f0b6e6323 # bad: [9f074d2a7bf49b2c9e1609703757b18de7611aef] Merge remote-tracking branch 'usb/usb-next' git bisect bad 9f074d2a7bf49b2c9e1609703757b18de7611aef # good: [855b2fdb7c543c94e7623e6ad0b492f04a5317db] Merge remote-tracking branch 'percpu/for-next' git bisect good 855b2fdb7c543c94e7623e6ad0b492f04a5317db # good: [1d08ed588c6a85a35a24c82eb4cf0807ec2b366a] usbip: vudc: fix missing unlock on error in usbip_sockfd_store() git bisect good 1d08ed588c6a85a35a24c82eb4cf0807ec2b366a # good: [1b7ce8fab5fd0c406dbf165b12d44b301decf589] Merge remote-tracking branch 'ipmi/for-next' git bisect good 1b7ce8fab5fd0c406dbf165b12d44b301decf589 # good: [fe8e488058c47e9a8a2c85321f7198a0a17b0131] dt-bindings: usb: mtk-xhci: add wakeup interrupt git bisect good fe8e488058c47e9a8a2c85321f7198a0a17b0131 # bad: [3c652132ce9052e626bf509932fcacfebed1ccb4] platform-msi: fix kernel-doc warnings git bisect bad 3c652132ce9052e626bf509932fcacfebed1ccb4 # bad: [7f2fac70b729d68a34e5eba8d1fb68eb69b05169] device property: Add test cases for fwnode_property_count_*() APIs git bisect bad 7f2fac70b729d68a34e5eba8d1fb68eb69b05169 # good: [38f087de8947700d3b06d3d1594490e0f611c5d1] devtmpfs: fix placement of complete() call git bisect good 38f087de8947700d3b06d3d1594490e0f611c5d1 # good: [b6f617df4fa936c1ab1831c2b23563f6c1add6c4] driver core: Update device link status properly for device_bind_driver() git bisect good b6f617df4fa936c1ab1831c2b23563f6c1add6c4 # bad: [6579c8d97ad7fc5671ee60234f3b8388abee5f77] clk: Mark fwnodes when their clock provider is added git bisect bad 6579c8d97ad7fc5671ee60234f3b8388abee5f77 # good: [ea718c699055c8566eb64432388a04974c43b2ea] Revert "Revert "driver core: Set fw_devlink=on by default"" git bisect good ea718c699055c8566eb64432388a04974c43b2ea # first bad commit: [6579c8d97ad7fc5671ee60234f3b8388abee5f77] clk: Mark fwnodes when their clock provider is added
On Tue, Apr 20, 2021 at 8:27 PM Guenter Roeck <linux@roeck-us.net> wrote: > > Hi, > > 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> > > This patch still causes a crash when booting a raspi2 image in linux-next. Stephen, Can we please just pick any one of the proposed fixes? This bug has been unfixed for so long! -Saravana > > [ 21.456500] Unable to handle kernel NULL pointer dereference at virtual address 00000028 > [ 21.456750] pgd = (ptrval) > [ 21.456927] [00000028] *pgd=00000000 > [ 21.457567] Internal error: Oops: 5 [#1] SMP ARM > [ 21.457882] Modules linked in: > [ 21.458077] CPU: 0 PID: 77 Comm: kworker/u8:10 Not tainted 5.12.0-rc8-next-20210420 #1 > [ 21.458291] Hardware name: BCM2835 > [ 21.458525] Workqueue: events_unbound deferred_probe_work_func > [ 21.458997] PC is at of_clk_add_hw_provider+0xbc/0xe8 > [ 21.459176] LR is at of_clk_add_hw_provider+0xa8/0xe8 > ... > [ 21.477603] [<c0a32aec>] (of_clk_add_hw_provider) from [<c0a32b60>] (devm_of_clk_add_hw_provider+0x48/0x80) > [ 21.477861] [<c0a32b60>] (devm_of_clk_add_hw_provider) from [<c0a471e4>] (raspberrypi_clk_probe+0x260/0x388) > [ 21.478087] [<c0a471e4>] (raspberrypi_clk_probe) from [<c0c1c4d0>] (platform_probe+0x5c/0xb8) > [ 21.478287] [<c0c1c4d0>] (platform_probe) from [<c0c19d84>] (really_probe+0xf0/0x39c) > [ 21.478471] [<c0c19d84>] (really_probe) from [<c0c1a098>] (driver_probe_device+0x68/0xc0) > [ 21.478659] [<c0c1a098>] (driver_probe_device) from [<c0c17f54>] (bus_for_each_drv+0x84/0xc8) > [ 21.478860] [<c0c17f54>] (bus_for_each_drv) from [<c0c19c20>] (__device_attach+0xec/0x158) > [ 21.479050] [<c0c19c20>] (__device_attach) from [<c0c18de8>] (bus_probe_device+0x88/0x90) > [ 21.479236] [<c0c18de8>] (bus_probe_device) from [<c0c16a68>] (device_add+0x398/0x8ac) > [ 21.479421] [<c0c16a68>] (device_add) from [<c0c1c1b4>] (platform_device_add+0xf0/0x200) > [ 21.479607] [<c0c1c1b4>] (platform_device_add) from [<c0c1ccc0>] (platform_device_register_full+0xd0/0x110) > [ 21.479836] [<c0c1ccc0>] (platform_device_register_full) from [<c104c130>] (rpi_firmware_probe+0x1a4/0x20c) > [ 21.480061] [<c104c130>] (rpi_firmware_probe) from [<c0c1c4d0>] (platform_probe+0x5c/0xb8) > [ 21.480255] [<c0c1c4d0>] (platform_probe) from [<c0c19d84>] (really_probe+0xf0/0x39c) > [ 21.480437] [<c0c19d84>] (really_probe) from [<c0c1a098>] (driver_probe_device+0x68/0xc0) > [ 21.480626] [<c0c1a098>] (driver_probe_device) from [<c0c17f54>] (bus_for_each_drv+0x84/0xc8) > [ 21.480829] [<c0c17f54>] (bus_for_each_drv) from [<c0c19c20>] (__device_attach+0xec/0x158) > [ 21.481018] [<c0c19c20>] (__device_attach) from [<c0c18de8>] (bus_probe_device+0x88/0x90) > [ 21.481205] [<c0c18de8>] (bus_probe_device) from [<c0c192bc>] (deferred_probe_work_func+0x8c/0xbc) > [ 21.481413] [<c0c192bc>] (deferred_probe_work_func) from [<c036802c>] (process_one_work+0x268/0x798) > [ 21.481624] [<c036802c>] (process_one_work) from [<c0368774>] (worker_thread+0x218/0x4f4) > [ 21.481822] [<c0368774>] (worker_thread) from [<c0370f28>] (kthread+0x140/0x174) > [ 21.481999] [<c0370f28>] (kthread) from [<c030017c>] (ret_from_fork+0x14/0x38) > [ 21.482185] Exception stack(0xc42b7fb0 to 0xc42b7ff8) > > Updated bisect log is attached. > > Guenter > > --- > # bad: [50b8b1d699ac313c0a07a3c185ffb23aecab8abb] Add linux-next specific files for 20210419 > # good: [bf05bf16c76bb44ab5156223e1e58e26dfe30a88] Linux 5.12-rc8 > git bisect start 'HEAD' 'v5.12-rc8' > # good: [c4bb91fc07e59241cde97f913d7a2fbedc248f0d] Merge remote-tracking branch 'crypto/master' > git bisect good c4bb91fc07e59241cde97f913d7a2fbedc248f0d > # good: [f15bbf170b40b48a43ed7076ce9f8ac9380e5752] Merge remote-tracking branch 'edac/edac-for-next' > git bisect good f15bbf170b40b48a43ed7076ce9f8ac9380e5752 > # bad: [550a78090dcc4061e191312a757a127f0b6e6323] Merge remote-tracking branch 'vfio/next' > git bisect bad 550a78090dcc4061e191312a757a127f0b6e6323 > # bad: [9f074d2a7bf49b2c9e1609703757b18de7611aef] Merge remote-tracking branch 'usb/usb-next' > git bisect bad 9f074d2a7bf49b2c9e1609703757b18de7611aef > # good: [855b2fdb7c543c94e7623e6ad0b492f04a5317db] Merge remote-tracking branch 'percpu/for-next' > git bisect good 855b2fdb7c543c94e7623e6ad0b492f04a5317db > # good: [1d08ed588c6a85a35a24c82eb4cf0807ec2b366a] usbip: vudc: fix missing unlock on error in usbip_sockfd_store() > git bisect good 1d08ed588c6a85a35a24c82eb4cf0807ec2b366a > # good: [1b7ce8fab5fd0c406dbf165b12d44b301decf589] Merge remote-tracking branch 'ipmi/for-next' > git bisect good 1b7ce8fab5fd0c406dbf165b12d44b301decf589 > # good: [fe8e488058c47e9a8a2c85321f7198a0a17b0131] dt-bindings: usb: mtk-xhci: add wakeup interrupt > git bisect good fe8e488058c47e9a8a2c85321f7198a0a17b0131 > # bad: [3c652132ce9052e626bf509932fcacfebed1ccb4] platform-msi: fix kernel-doc warnings > git bisect bad 3c652132ce9052e626bf509932fcacfebed1ccb4 > # bad: [7f2fac70b729d68a34e5eba8d1fb68eb69b05169] device property: Add test cases for fwnode_property_count_*() APIs > git bisect bad 7f2fac70b729d68a34e5eba8d1fb68eb69b05169 > # good: [38f087de8947700d3b06d3d1594490e0f611c5d1] devtmpfs: fix placement of complete() call > git bisect good 38f087de8947700d3b06d3d1594490e0f611c5d1 > # good: [b6f617df4fa936c1ab1831c2b23563f6c1add6c4] driver core: Update device link status properly for device_bind_driver() > git bisect good b6f617df4fa936c1ab1831c2b23563f6c1add6c4 > # bad: [6579c8d97ad7fc5671ee60234f3b8388abee5f77] clk: Mark fwnodes when their clock provider is added > git bisect bad 6579c8d97ad7fc5671ee60234f3b8388abee5f77 > # good: [ea718c699055c8566eb64432388a04974c43b2ea] Revert "Revert "driver core: Set fw_devlink=on by default"" > git bisect good ea718c699055c8566eb64432388a04974c43b2ea > # first bad commit: [6579c8d97ad7fc5671ee60234f3b8388abee5f77] clk: Mark fwnodes when their clock provider is added
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);
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(+)