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

[Marek Vasut]

On 9/25/24 8:48 PM, Saravana Kannan wrote:

Hi,

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

I sent out V2.

> 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/
>
> > I know, I am unsure how to proceed with this. Convert this to
> > platform_driver or some such and probe it early maybe ?
>
> Marek,
>
> Thanks for trying out drive_async_probe=* and trying to fix boards/drivers.

That was one of the most useful things I picked at LPC this year, thanks.

> The issue you are facing and the proper way to handle it was covered
> in my talk at LPC 2024 in Slide 18:
> https://lpc.events/event/18/contributions/1734/
>
> All the benefits of fw_devlink are only present for drivers that use a
> device-driver model. And yes, in this case we should convert this
> driver into a platform device/driver if it's possible.
Done in V2, thanks.