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: <37634d8e-678e-45ba-98e9-a40a5e71cf77@app.fastmail.com>
Date: Wed, 25 Sep 2024 20:00:00 +0000
From: "Arnd Bergmann" <arnd@...db.de>
To: "Saravana Kannan" <saravanak@...gle.com>, "Marek Vasut" <marex@...x.de>
Cc: 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 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.

> 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