> On Sat, 2007-04-07 at 13:08 -0700, David Brownell wrote: > > On Friday 06 April 2007 10:01 pm, Greg KH wrote: > > > > > Are you _sure_ you have a 1-to-1 relationship here? No multiple devices > > > pointing to the same acpi node? Or the other way around? If so, you > > > are going to have to change the name to be something more unique. > > > > I've wondered that too. The short answer: APCI only supports 1-1 > > here. > > Right. > > > It will emit warnings if it tries to bind more than one ACPI > > device to a given "real" device ... but errors the other way are > > silently ignored. > > My understanding is different. > First, one "real" device can only have one device.archdata.acpi_handle, > which means it can only be bound to one ACPI device. > Second, AE_ALREADY_EXISTS will be returned when ACPI tries to bind more > than one "real" devices to the same ACPI device. Exactly. The "first" case emits a warning, the "second" case doesn't; no matter what it is (though I only saw ALREADY_EXISTS). When I added a warning to that case: > > By adding a warning over this create-links patch, I found that the > > system in the $SUBJECT patch (and likely every ACPI system) has > > two different nodes that correspond to one ACPI node: > > > > /sys/devices/pci0000:00 ... pci root node > > /sys/devices/pnp0/00:00 ... id PNP0a03 > > /sys/devices/acpi_system:00/device:00/PNP0A03:00 ... ditto > > > > Arguably that's too many sysfs nodes for one device... Presumably you've noticed this same thing (not necessarily pnp0/00:00) on other systems ... > > Plus, there's the issue of flakey ACPI tables; in the $SUBJECT patch > > both MDM and AUD nodes exist in the ACPI namespace, but they could > > only refer to one PCI device (with MDM as the wakeup source, not AUD > > as listed in the table). Or maybe that's another case where the ACPI > > code isn't handling the tables as sensibly as it might... > > Could you attach this acpidump please? :) Off-list; yes. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
