Bug#454493: Display PCI slot for nics, if available
On Wed, Dec 05, 2007 at 05:03:41PM -0200, Otavio Salvador wrote:
> dann frazier <dannf@debian.org> writes:
>
> > Currently this patch only attempts to load the acpiphp driver - it
> > should probably try and load others as well (e.g. pciehp & shchp, and
> > the future possible pci_slot).
>
> Why acpihp isn't loaded by udev automaticaly?
I'm probably not the best person to answer that question, but I can
give you some handwavy guesswork :)
I'm guessing that you're asking this because you've seen other pci
hotplug drivers get loaded by udev. I've noticed this too - shpchp
loads on some of my boxes, so I looked to see why. Turns out that
shpchp registers itself as a driver for pci devices that are in the
pci bridge class, so this mapping is available to udev in
modules.pcimap.
acpiphp doesn't register itself for any pci devices - in fact, the
machine I test on doesn't show any pci bridges devices in lspci, so
I'm assuming they're transparent to udev as well. The devices on this
bridge work just fine, they are just not hotpluggable until the
acpiphp module is loaded.
I wondered if this was always the case with ACPI-described bridges, so
I asked Matthew Wilcox:
<dannf> willy: is it the case that pci bridges described by ACPI never
(or not always) appear as pci devices themselves?
<willy> dannf: No correlation. If they're PCI-PCI bridges, they will
show up in the PCI namespace, but there's no way to tell
whether or not they support acpiphp
I believe that currently the only way to know if a machine supports
acpiphp is to load it. This seems to match up pretty well with my
observations of other acpi drivers. acpid seems to take ownership of
loading acpi modules like battery, fan, thermal, etc - it simply
modprobes them and lets the driver do the discovery. Maybe it should
also be loading acpiphp? Perhaps.
Does d-i do anything wrt loading acpi drivers today (other than
installing acpid into the target)?
--
dann frazier
Reply to: