On Mon, Mar 29, 2021 at 2:25 PM Stephen Boyd <sboyd@xxxxxxxxxx> wrote: > > Quoting Geert Uytterhoeven (2021-03-26 11:29:55) > > On Fri, Mar 26, 2021 at 7:13 PM Stephen Boyd <sboyd@xxxxxxxxxx> 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.
