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
| ||
|
Date: Wed, 31 Oct 2012 19:42:13 +0100 From: "Rafael J. Wysocki" <rjw@...k.pl> To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "H. Peter Anvin" <hpa@...or.com>, Tony Luck <tony.luck@...el.com> Cc: LKML <linux-kernel@...r.kernel.org>, Linux PM list <linux-pm@...r.kernel.org>, ACPI Devel Maling List <linux-acpi@...r.kernel.org>, Len Brown <lenb@...nel.org>, Mathias Nyman <mathias.nyman@...ux.intel.com>, Mika Westerberg <mika.westerberg@...ux.intel.com>, Lv Zheng <lv.zheng@...el.com>, Huang Ying <ying.huang@...el.com>, Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, x86 list <x86@...nel.org> Subject: Re: [PATCH 1/5] driver core / ACPI: Move ACPI support to core device and driver types On Wednesday, October 31, 2012 09:24:07 AM Greg Kroah-Hartman wrote: > On Wed, Oct 31, 2012 at 10:38:29AM +0100, Rafael J. Wysocki wrote: > > From: Mika Westerberg <mika.westerberg@...ux.intel.com> > > > > With ACPI 5 we are starting to see devices that don't natively support > > discovery but can be enumerated with the help of the ACPI namespace. > > Typically, these devices can be represented in the Linux device driver > > model as platform devices or some serial bus devices, like SPI or I2C > > devices. > > > > Since we want to re-use existing drivers for those devices, we need a > > way for drivers to specify the ACPI IDs of supported devices, so that > > they can be matched against device nodes in the ACPI namespace. To > > this end, it is sufficient to add a pointer to an array of supported > > ACPI device IDs, that can be provided by the driver, to struct device. > > > > Moreover, things like ACPI power management need to have access to > > the ACPI handle of each supported device, because that handle is used > > to invoke AML methods associated with the corresponding ACPI device > > node. The ACPI handles of devices are now stored in the archdata > > member structure of struct device whose definition depends on the > > architecture and includes the ACPI handle only on x86 and ia64. Since > > the pointer to an array of supported ACPI IDs is added to struct > > device_driver in an architecture-independent way, it is logical to > > move the ACPI handle from archdata to struct device itself at the same > > time. This also makes code more straightforward in some places and > > follows the example of Device Trees that have a poiter to struct > > device_node in there too. > > > > This changeset is based on Mika Westerberg's work. > > > > Signed-off-by: Mika Westerberg <mika.westerberg@...ux.intel.com> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com> > > --- > > arch/ia64/include/asm/device.h | 3 --- > > arch/x86/include/asm/device.h | 3 --- > > drivers/acpi/glue.c | 14 ++++++-------- > > include/acpi/acpi_bus.h | 2 +- > > include/linux/device.h | 4 ++++ > > 5 files changed, 11 insertions(+), 15 deletions(-) > > The driver core pieces look fine to me: > > Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org> Great, thanks! I wonder if the x86 and/or ia64 maintainers have any reservations? Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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