> -----Original Message----- > From: Greg Kroah-Hartman [mailto:gre...@linuxfoundation.org] > Sent: Thursday, December 19, 2013 4:32 PM > To: Wood Scott-B07421 > Cc: Yoder Stuart-B08248; Kim Phillips; linux-kernel@vger.kernel.org; > k...@vger.kernel.org; Bhushan Bharat-R65777; christoffer.d...@linaro.org; > alex.william...@redhat.com; a.mota...@virtualopensystems.com; > ag...@suse.de; 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:gre...@linuxfoundation.org] > > > > > Sent: Thursday, December 19, 2013 2:34 PM > > > > > To: Wood Scott-B07421 > > > > > Cc: Kim Phillips; linux-kernel@vger.kernel.org; > k...@vger.kernel.org; > > > > > Bhushan Bharat-R65777; Yoder Stuart-B08248; > christoffer.d...@linaro.org; > > > > > alex.william...@redhat.com; a.mota...@virtualopensystems.com; > > > > > ag...@suse.de; 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/