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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGETcx-=UvJx1C9nNYzLP7v1T6sELN3QPzfbZT==b83LUAC=VQ@mail.gmail.com>
Date: Wed, 25 Sep 2024 13:04:39 -0700
From: Saravana Kannan <saravanak@...gle.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Marek Vasut <marex@...x.de>, linux-arm-kernel@...ts.infradead.org, 
	kernel@...electronics.com, 
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, 
	Fabio Estevam <festevam@...il.com>, Jeff Johnson <quic_jjohnson@...cinc.com>, 
	Neil Armstrong <neil.armstrong@...aro.org>, Pengutronix Kernel Team <kernel@...gutronix.de>, 
	Sascha Hauer <s.hauer@...gutronix.de>, Shawn Guo <shawnguo@...nel.org>, imx@...ts.linux.dev, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] soc: imx8m: Probe the SoC driver late

On Wed, Sep 25, 2024 at 1:00 PM Arnd Bergmann <arnd@...db.de> wrote:
>
> On Wed, Sep 25, 2024, at 18:48, Saravana Kannan wrote:
> > On Wed, Sep 25, 2024 at 10:07 AM Marek Vasut <marex@...x.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.

Sweet!

Marek, now you know what to do :)

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

Great to hear it was useful!

-Saravana