On Tue, Sep 22, 2026 at 10:33:16AM +0200, Uwe Kleine-König wrote:
> Hello,
> 
> On Mon, Sep 21, 2026 at 06:24:39PM +0200, Thierry Reding wrote:
> > You're probably not wrong about opt-in being the more natural choice,
> > but looking at commit 3d713e0e382e ("driver core: platform: add device
> > binding path 'driver_override'"), the intended use-cases are very
> > generic, so it would probably lead to a continuous stream of patches
> > needing to be added whenever a new device wants to be supported with
> > vfio or something.
> 
> thinking a bit more about that: The use-case presented in that commit is
> about
> 
> 	echo vfio-platform > /sys/bus/platform/devices/fff51000.ethernet/driver_override
> 
> . If we had an opt-in mechanism on the driver side, it would only be
> vfio* that would need it, wouldn't it? That sounds handleable.

I have a prototype patch that I'm going to send out shortly (after
testing that it actually works). The problem ended up being that the
driver_override is a device attribute, so there's no good way to drop it
based on a driver flag.

What I ended up doing was add a flag to the driver that causes the
override matching to abort if the driver doesn't allow it.

And yes, you could probably do this the other way around and require
drivers to opt-in, but given how long this has been there and how
generic the interface is (and it is ABI after all), I don't know if
vfio-platform is the only one where this is being used. For all we know
there could be a myriad of odd use-cases where people are using this in
one way or another.

I was briefly pondering a more automatic way where we'd check for the
presence of any device ID match tables and checking the device data
pointers, but that's a bad heuristic since there's nothing stopping
anyone from providing "sensible" defaults if there is not matched data.

So ultimately I think individual drivers opting out of this behaviour if
they explicitly don't want to support it is probably the only safe way
to do it.

Thierry