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] [day] [month] [year] [list]

Message-ID: <7383cd9f-6e70-4b3a-96a4-98170e584a7b@denx.de>
Date: Thu, 26 Sep 2024 00:11:13 +0200
From: Marek Vasut <marex@...x.de>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Arnd Bergmann <arnd@...db.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 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.