Re: [PATCH] pinctrl: mcp23s08: reject devices without match data

[Danilo Krummrich]

On Sun Oct 4, 2026 at 10:15 AM CEST, Andy Shevchenko wrote:
> +Cc: Danilo
> (as you were involved in cleaning this up in the past and being co-maintainer
>  of driver core)
>
> On Sun, Oct 04, 2026 at 01:06:07AM +0200, Linus Walleij wrote:
>> On Fri, Oct 2, 2026 at 12:19 PM Andy Shevchenko
>> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
>> > On Fri, Oct 02, 2026 at 11:52:41AM +0200, Linus Walleij wrote:
>> > > On Fri, Oct 2, 2026 at 8:59 AM Andy Shevchenko
>
> ...
>
>> > > The entire name of the thing feels like debugfs-footgun
>> > > territory for example.
>> >
>> > Yeah, I can't find neither a thing on LWN.net nor in the in-tree documentation.
>> > The only useful piece of information is (in kernel-doc of struct bus_type):
>> >
>> >   driver_override
>> >     Set to true if this bus supports the driver_override mechanism, which
>> >     allows userspace to force a specific driver to bind to a device via a sysfs
>> >     attribute.
>> 
>> This whole thing is weird, but OK.
>> 
>> Since we have a ton of drivers depending on match data we either
>> have to patch them all to bail out if match data is NULL (like this
>> patch does) or, which is equivalent, opt out of driver_override
>> that much is certain.
>> 
>> What I don't get is what this is intended for. What is the use case?
>> The commit says this is for VFIO. Shouldn't it be opt-in and turned
>> on only for VFIO then?

I think VFIO could use a different (less generic) mechanism that is more
integrated with the corresponding bus to e.g. allow userspace to decide to get a
PF bound to a VFIO driver for passthrough.

The existing driver_override is convinient for this case, but ideally we want to
express that a driver can only be bound to the corresponding host and VFIO
drivers.

I think the situation for SPI is pretty similar.

Unfortunately, it is a uAPI already, so we can't really get rid of it.

But I agree that we should be more defensive about this and make it a driver
opt-in. Uwe already prepared a patch for this [1].

[1] https://lore.kernel.org/driver-core/0f7446324f6a0c8f0153d6532d92a6eeecd6a308.1790612298.git.u.kleine-koenig@xxxxxxxxxxxx/