Re: [PATCH] PCI Hotplug: fakephp: fix deadlock... again

[Andrew Patterson]

On Mon, 2008-09-08 at 22:27 -0600, Matthew Wilcox wrote:
> On Mon, Sep 08, 2008 at 09:12:29PM -0700, Jesse Barnes wrote:
> > I don't have a preference here; whatever is most useful for people is probably 
> > what we should go for.  Zhao?
> 
> I think we have two distinct groups of users; those who find emulating
> slot hotplug useful, and those who want to hot-remove pci functions.
> Maybe hot-removing a pci function should not be part of the pci hotplug
> core per se -- obviously it would share much code -- but being able
> to hot-remove a function is a fundamentally different thing from being
> able to hot-remove a slot.  For example, hot-removing a function from a
> device that is in a real hotplug slot should be possible, but it wouldn't
> involve the driver for that hotplug slot.
> 
> So maybe what we want is a /sys/bus/pci/devices/dddd:bb:dd.f/remove file
> that does just that.
> 

of something like "disable", so we can enable it again?

> Oh, and we also want a way to hot-add functions, not necessarily even
> ones that have been removed from the machine after it was booted, but
> those that show up after the machine has booted.  For example, one of
> my former colleagues had a laptop which would remove the wireless pci
> device from the bus if the rfkill switch was enabled.  I remember there
> was a hack to load a module that called some pci bus rescan functionality.
> I didn't look into it in much detail.
> 
> I don't have a firm idea about an interface for this.  SCSI handles it by
> writing scsi-add-single-device H C T L to /proc/scsi/scsi.  Maybe we want
> a /sys/bus/pci/scan or /sys/bus/pci/devices/scan file that we can echo
> "0000:01:02.3" to scan just that function, or "0000:01:02" to scan the
> device.
> 

I like this idea. Even perhaps add a recursive scan to rescan behind a
bridge?

-- 
Andrew Patterson
Hewlett-Packard

--
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/