linux-kernel - Re: [PATCH 5/5] ACPI: Tie ACPI backlight devices to PCI devices if possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201102070034.43691.rjw@sisk.pl>
Date:	Mon, 7 Feb 2011 00:34:43 +0100
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Matthew Garrett <mjg59@...f.ucam.org>,
	dri-devel@...ts.freedesktop.org
Cc:	akpm@...ux-foundation.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, rpurdie@...ys.net,
	Len Brown <lenb@...nel.org>
Subject: Re: [PATCH 5/5] ACPI: Tie ACPI backlight devices to PCI devices if possible

On Monday, February 07, 2011, Matthew Garrett wrote:
> On Mon, Feb 07, 2011 at 12:01:25AM +0100, Rafael J. Wysocki wrote:
> 
> > Yes, it seems so, but I'm not sure what the short term consequences of that
> > change will be.  Perhaps there will be none. :-)
> 
> Ok, I'll have a play with that. Maybe we should be fixing this up 
> somehow in the acpi-pci glue code? It seems wrong to have acpi devices 
> resumed before the PCI device they're associated with.

Those device's don't have ACPI drivers and therefore they are not really
suspended or resumed, so we don't need to fix anything in that area.

Still, IMO, there is a design issue in the entire ACPI subsystem, because the
idea of "ACPI device" really is not well defined, so to speak.  Sometimes
they are just "device interfaces" that can be used to ask the firmware for
something (like in the case of the "ACPI devices" associated with PCI devices)
and sometimes they are "real devices" with real drivers.  The video device
apparently wants to be both at the same time, which is even more confusing. :-)

I _think_ that struct acpi_device shouldn't really contain the embedded device
object and each of struct acpi_device objects should be pointed to by the
archdata member of certain struct device.  In turn, struct acpi_device should
contain a pointer to the struct device that it's pointed to by via the archdata
field.  Then, the struct acpi_device objects will always be "device interfaces"
and all of the device-driver interactions will be represented through their
corresponding device objects.  That should allow us to avoid all of the
suspend-resume complications (and all sorts of other ugliness).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/