RE: [REPOST][PATCH 1/2] driver core: Add new device_driver flag toallow binding via sysfs only

[Stuart Yoder]

> -----Original Message-----
> From: Greg Kroah-Hartman [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, December 19, 2013 4:32 PM
> To: Wood Scott-B07421
> Cc: Yoder Stuart-B08248; Kim Phillips; linux-kernel@xxxxxxxxxxxxxxx;
> kvm@xxxxxxxxxxxxxxx; Bhushan Bharat-R65777; christoffer.dall@xxxxxxxxxx;
> alex.williamson@xxxxxxxxxx; a.motakis@xxxxxxxxxxxxxxxxxxxxxx;
> agraf@xxxxxxx; Sethi Varun-B16395
> Subject: Re: [REPOST][PATCH 1/2] driver core: Add new device_driver flag
> to allow binding via sysfs only
> 
> On Thu, Dec 19, 2013 at 04:15:03PM -0600, Scott Wood wrote:
> > On Thu, 2013-12-19 at 13:43 -0800, Greg Kroah-Hartman wrote:
> > > On Thu, Dec 19, 2013 at 09:06:21PM +0000, Stuart Yoder wrote:
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Greg Kroah-Hartman [mailto:gregkh@xxxxxxxxxxxxxxxxxxx]
> > > > > Sent: Thursday, December 19, 2013 2:34 PM
> > > > > To: Wood Scott-B07421
> > > > > Cc: Kim Phillips; linux-kernel@xxxxxxxxxxxxxxx;
> kvm@xxxxxxxxxxxxxxx;
> > > > > Bhushan Bharat-R65777; Yoder Stuart-B08248;
> christoffer.dall@xxxxxxxxxx;
> > > > > alex.williamson@xxxxxxxxxx; a.motakis@xxxxxxxxxxxxxxxxxxxxxx;
> > > > > agraf@xxxxxxx; Sethi Varun-B16395
> > > > > Subject: Re: [REPOST][PATCH 1/2] driver core: Add new
> device_driver flag
> > > > > to allow binding via sysfs only
> > > > >
> > > > > No.  But you can use bind/unbind along with the existing new_id
> file to
> > > > > get what you want today.
> > > >
> > > > Yes, but that only works for PCI.
> > >
> > > No, not only PCI.
> > >
> > > > There is no such concept for platform drivers.
> > >
> > > Then fix that.
> >
> > We've already explained why that would be bad.
> 
> No you haven't, or if you have, my squirrel-brain doesn't remember it...
> 
> > > Or make your device not be a platform device, odds are that's the
> better
> > > solution in the end, right?
> >
> > How would that solve anything?  We'd just be talking about there not
> > being such a mechanism for the device tree "bus" instead.
> 
> Nope, you could add it there, like PCI and other busses have.
> 
> > > > > I don't like this patch as we are adding lots of special and odd
> logic
> > > > > to the core, for use by almost no one, which ensures that it will
> never
> > > > > get tested, and will probably get broken in some subtle way in
> the
> > > > > future.
> > > >
> > > > It certainly will be used by users of vfio-platform.
> > > >
> > > > Here is the problem-- the new platform device "match_any_dev"
> mechanism
> > > > in patch 2 of this series is not going to work without
> "sysfs_bind_only".
> > > > A platform driver that just sets "match_any_dev" will grab any or
> all
> > > > platform devices during normal bus probing.
> > >
> > > No it will not, it will fail in the probe function as it knows to not
> > > grab the device, just like any driver for other busses that say it
> can
> > > "handle all Intel PCI devices" and the like.
> >
> > How will it "know not to grab the device"?  The knowledge of whether
> the
> > binding was explicitly requested or not does not get passed through to
> > the probe function.
> 
> Nor should it, as a driver should not know, nor care about this.
> 
> It's up to the BUS to handle this if it really wants to, and I'm afraid
> that I really am not convinced that the driver core needs to handle it
> either.
> 
> But again, as you don't have anything that could actually use this code
> that is mergable, it's a totally moot point, sorry.

Understand, but what assumption do we develop vfio-plaform with?  That
a driver core 'sysfs_bind_only' flag is not an option, period?  If that
is the case we need to go back to square one and invent some new mechanism
to bind devices to the vfio-platform driver.

I guess it would need to be the platform bus equivalent of new_id.

But, then we're left with the potential racy situation where multiple drivers
can potentially grab a device and it's ambiguous and non-deterministic at to which
driver binds to it.

Stuart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/