On Thursday 20 March 2008, Zhao Yakui wrote: > On Thu, 2008-03-20 at 14:09 -0700, David Brownell wrote: > > From: David Brownell <dbrownell@xxxxxxxxxxxxxxxxxxxxx> > > > > Add cross-links between ACPI device and "real" devices in sysfs, > > exposing otherwise-hidden interrelationships between the various > > device nodes which ACPI creates. As a representative example one > > hardware device is exposed as two logical devices (PNP and ACPI): > > > > .../pnp0/00:06/ > > .../LNXSYSTM:00/device:00/PNP0A03:00/device:15/PNP0B00:00/ > > > > The PNP device gets a "firmware_node" link pointing to the ACPI device. > > The ACPI device has a "physical_node" link pointing to the PNP device. > > Linux drivers currently bind only to the "physical" device nodes. > > Very good idea. > But maybe there is a lot of ACPI devices on the laptops. And we take a > little care about the association between the acpi device and "real" > device. Are you suggesting that the ACPI nodes shouldn't exist at all? Or that something is wrong with how they're set up or used? For now, there's some confusion. Devices listed in ACPI tables have one or two extra sysfs device nodes. I think *something* should help sort out the confusion -- this patch (originally from Zhang Rui, a co-worker of yours) is the only help for that which I've seen so far. Do you propose some other solution? If so, what is it ... and what are its advantages? > Maybe it is more useful if the link is set up for the acpi device with > the _PRW object. Maybe the link that points to ACPI device with the _PRW > object is created in the /sys/power/. That's way too many "maybes" for my taste! Maybe I don't see how "_PRW" could be the only interesting thing, when most of the ACPI nodes don't even *have* such records ... and when not all power-manageable devices are even known to ACPI. The notion of adding ACPI-specific stuff to generic areas (like /sys/power) really bothers me... - 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
