On Tue, Sep 22, 2026 at 12:06:14PM +0200, Thierry Reding wrote:
> 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.

Did you see that I sent such a patch already.
https://lore.kernel.org/lkml/0f7446324f6a0c8f0153d6532d92a6eeecd6a308.1790612298.git.u.kleine-koenig@baylibre.com/ .
You were on Cc:, I thought this to be enough to make you aware and
didn't mention it in this thread here.

I hope to not have provoked much duplicate work.

Best regards
Uwe