Re: [PATCH] soc: imx8m: Probe the SoC driver late

["Arnd Bergmann" <arnd@arndb.de>]

On Wed, Sep 25, 2024, at 18:48, Saravana Kannan wrote:
> On Wed, Sep 25, 2024 at 10:07 AM Marek Vasut <marex@denx.de> wrote:
>> >
>> > Right, of course. And unfortunately it can't just register to
>> > the fsl,imx8mm-anatop/fsl,imx8mm-ocotp/... nodes because they
>> > all have a driver already.
>
> Can't we change this to add a platform device and a platform driver in
> the initcall? And then the driver can return -EPROBE_DEFER if it can't
> get the clock yet?

Yes, good idea. So the initcall would still use of_match_node()
to see if wants to be loaded and then either bail early or
call platform_create_bundle() to register the driver and the
device.

>> > On the other hand, making it a late_initcall() defeats the
>> > purpose of the driver because then it can't be used by other
>> > drivers with soc_device_match(), resulting in incorrect
>> > behavior when another driver relies on this to enable
>> > a chip revision specific workaround.
>
> We could have soc_device_match() return -EPROBE_DEFER if no soc device
> has been registered yet.
>
> For cases where it's already working without any changes, we shouldn't
> see any new -EPROBE_DEFER return values. But for cases like what Marek
> is trying to do, it should work properly. He might have to fix bad
> driver code where they remap the error instead of returning it as is.

Right.

> On a tangential note, the soc framework seems to be yet another
> framework violating the bus vs class thing. If it's a bus, then you
> need to have a probe. Otherwise, just make it a class. Might be too
> much to fix at this point, but might be good to keep this in mind if
> you plan to write more frameworks or redo soc framework at some point
> :)
>
> See Slide 20:
> https://lpc.events/event/18/contributions/1734/

Very useful, I don't think I've seen this explained like this
in the past. It's probably not easy to change now since I'm
sure there is existing userspace looking at /sys/bus/soc, but
I can at least make sure I'll follow these when reviewing new
bus_type or class submissions.

     Arnd