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

[Gatien CHEVALLIER]

On 2/25/26 21:38, Danilo Krummrich wrote:
> On Wed Feb 25, 2026 at 9:19 PM CET, Cristian Marussi wrote:
> > it has been reported by Gatien (in CC) that this break the SCMI OPTEE
> > transport.
> >
> > Moreover I still have to verify, BUT I think this also breaks SCMI
> > Virtio transport since both call platform_driver_register() during their
> > probe, since a few years ago the SCMI transports have been reworked to be
> > standalone full-fledged drivers.
>
> I've had a quick look and I'm pretty sure that both transports/virtio.c and
> transports/optee.c are broken.
>
> Both cases look identical and I think the fix should be as trivial as moving
> platform_driver_register() into module_init().

Hello,

(Regarding OP-TEE SCMI transport)

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.

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?

Gatien

> > I'll have a look in the next days if we can cope with this.
>
> I already fixed those three [1,2,3]. If you can provide a patch for both of
> them, that'd be great. Otherwise, please let me know if you want me to send
> something.
>
> Thanks,
> Danilo
>
> [1] https://lore.kernel.org/driver-core/20260121141215.29658-1-dakr@xxxxxxxxxx/
> [2] https://lore.kernel.org/driver-core/20260123133614.72586-1-dakr@xxxxxxxxxx/
> [3] https://lore.kernel.org/driver-core/20260212235842.85934-1-dakr@xxxxxxxxxx/