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: <201102071432.35656.bjorn.helgaas@hp.com>
Date:	Mon, 7 Feb 2011 14:32:35 -0700
From:	Bjorn Helgaas <bjorn.helgaas@...com>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	dri-devel@...ts.freedesktop.org, 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 Sunday, February 06, 2011 04:34:43 pm Rafael J. Wysocki wrote:
> 
> 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'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.

Bjorn
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ