On 11/11/2012 01:21 PM, Greg Kroah-Hartman wrote: > On Sat, Nov 10, 2012 at 09:57:14PM +0800, Jiang Liu wrote: >> From: Jiang Liu <jiang.liu@xxxxxxxxxx> >> >> There are several requirements to temporarily reject device driver >> binding. Possible usage cases as below: >> 1) We should avoid binding an unsafe driver to a device belonging to >> an active VFIO group, otherwise it will break the DMA isolation >> property of VFIO. >> 2) When hot-removing a PCI hierachy, we should avoid binding device >> drivers to PCI devices going to be removed during the window >> between unbinding of device driver and destroying of device nodes. >> 3) When hot-adding a PCI host bridge, we should temporarily disable >> driver binding before setting up corresponding IOMMU and IOAPIC. >> >> We may add a flag into struct device to temporarily disable driver >> binding as in this thread https://patchwork.kernel.org/patch/1535721/. > > I totally do not understand. The bus controls this, if it does not want > to bind a device to a driver, then don't do it. It's really quite > simple to just block the probe callback the bus gets, right? Why create > all of this extra, and confusing, interface instead? Hi Greg, Thanks for your comments. As you know, we already have an "drivers_autoprobe" flag for drivers, we are trying to provide a similar mechanism for devices. But I'm not sure whether we could block the probe callback. For PCI host bridge hotplug, that will effectively block the PCI host bridge hotplug thread. For VFIO case, its goal is to reject binding unsafe drivers to PCI devices belonging to active VFIO group, so it doesn't make sense to block the driver probing thread too. So we are trying to return error code instead of blocking in really_probe(). Thanks! Gerry > >> This patch proposes another solution to temporarily disable driver >> binding by using bus notification mechanisms. It adds an notification >> event to solicit if anybody has objections when binding a driver to a >> device. > > Sorry, but no, don't do this, it's way more confusing. > > greg k-h > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html