On Monday, February 07, 2011, Matthew Garrett wrote:

On Mon, Feb 07, 2011 at 02:32:35PM -0700, Bjorn Helgaas wrote:

quoted

I'm not familiar with video devices, but I agree, this situation does
feel broken.  Is it the case that there's a PCI device as well as an
ACPI namespace Device for the same piece of hardware?  If so, I assume
the reason for the ACPI Device is to have a "standard" interface to
a platform knob like backlight control.

In that case, it seems like we should rely on PCI for enumeration and
driver binding, have some sort of hook the PCI driver could use to
twiddle that knob (using the ACPI methods), and make the ACPI Device
ineligible for driver binding.  In other words, it sounds like part
of the problem is that we have two drivers binding to what's really
a single piece of hardware.

Part of the problem is that ACPI video devices aren't inherently PCI 
devices.

To me, this really isn't about video devices.  The problem is that objects
of type struct acpi_device are treated _differently_ depending on the context.

In the meantime I've reviewed the code a bit and noticed that there's a
parent pointer in struct acpi_device, which basically duplicates the device
tree dependency, so it looks like the embedded dev in struct acpi_device is
really redundant.