Re: [PATCH v5] driver core: enforce device_lock for driver_match_device()

[Cristian Marussi]

On Thu, Feb 26, 2026 at 12:15:33PM +0100, Danilo Krummrich wrote:
> On Thu Feb 26, 2026 at 9:54 AM CET, Gatien CHEVALLIER wrote:

Hi,

I think my mail thread is a bit messed up...my previous reply is nowhere
to be found, so I will repeat here...

> > It may not be that trivial because unconditionally moving it to
> > module_init() would not guarantee that the TEE bus driver probes
> > before the platform device driver. I think there's a bit more to it.

@Gatien

Yes, it is just what I was going to reply...these SCMI transport drivers
basically have to probe first against their related subsystem like
OPTEE/Virtio and then, only when fully probed at this level, are fully
functional and can become a transport supplier for the SCMI core...
...registering the platform driver at the end of the OPTEE/VIRTIO probe
allowed to avoid any kind of EPROBE_DEFER handling that can come up
espcially when all of this is split into loadable modules..

...I have to review this in deep but I think I had a first version of these
transport rework that worked a bit differently...

> >
> > The platform device driver, as is, is not functional whilst the
> > TEE services are not available. Therefore, it could falsely fail to
> > probe if probed before. We may consider some sort of API to know if
> > the services are available?
> 
> Ok, so there are three drivers somehow involved:
> 
>   (1) module_tee_client_driver(scmi_optee_service_driver)
> 
>   (2) scmi_optee_driver with compatible = "linaro,scmi-optee"
> 
>   (3) scmi_driver with name = "arm-scmi"
> 
> (1) registeres (2) in probe(), and the only thing (2) does is allocating a
> platform_device with name = "arm-scmi", such that (3) is probed.
> 
> So, to me it seems that the indirection through a fake platform device is
> unnecessary and instead (3) should just have compatible = "linaro,scmi-optee"

@Danilo

That was the initial state, all the transports and related compatibles embedded
into the SCMI core stack...then we split out the transport as loadable standalone
drivers, since it seemed to be cleaner (and some vendor also asked for by that
time...).

	https://lore.kernel.org/arm-scmi/20240812173340.3912830-1-cristian.marussi@xxxxxxx/

> and return -EPROBE_DEFER if (1) is not ready. Besides that, this seems like a
> use-case for device links.

We tried to unify the handling because other transports (mailbox/smc) do
NOT rely on 3rd party subsystem to be initialized and this approach
indeed simplified all because you dont need any DEFER simply because
the SCMI core probing will be kicked off ONLY after at least a transport
is successfully probed and initialized...there is a devlink indeed later
that classifies the used transport as a supplier of the core SCMI
arm-scmi driver...

I have to recall the full details especially of the reqs that led to
this design bit I suppose we should at this point reintroduce a bit of
EDEFER...

Thanks,
Cristian