On Thu, 10 Sep 2009 10:31:57 -0600 Bjorn Helgaas <bjorn.helgaas@xxxxxx> wrote: > On Monday 07 September 2009 04:40:22 am Eric W. Biederman wrote: > > > > What follows below is my alternate pcie hotplug driver. > > It is very stupid, very simple and very robust. > > > > This driver should work on any pcie hotplug bridge that > > only has support for the interrupt when the pcie link > > comes or down, and that sets the hotplug and the hotplug > > surprise bits. > > > > I wrote this because in my environment the pciehp driver > > totally fails and 500 lines of code are much easier to > > debug than 3000. > > > > Now that I have the code working I'm looking for the best > > path to get a driver I can use into the mainstream kernel. > > I think it'd be great to simplify pciehp, and pcielw looks > nice and clean. > > I think pciehp/acpiphp/pcielw are somewhat user-unfriendly > because (a) it's hard for a user to figure out which to use, > and (b) there's no nice way to autoload them because there's > nothing that connects them to a udev event. > > My personal opinion is that we shouldn't merge pcielw alongside > pciehp because it would make the user confusion worse and dilute > the already small testing pool. > > We could address the autoload issue by making pciehp/pcielw part > of the pcieport driver. That would simplify the code as well as > the user experience, but maybe there's some reason to keep them > separate. > > I think it'd be nice to have a series of evolutionary patches > to transform pciehp rather than replacing it wholesale. Otherwise, > bisection (one of the few tools we non-expert masses have) won't > be as useful. Agreed. Is that something you'd be interested in doing, Eric? We have a fairly active hotplug community (most of the patches in any given release seem to be hotplug related) so you shouldn't have a shortage of testers... -- Jesse Barnes, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html