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: Thu, 5 Mar 2015 13:56:24 +0100 From: "Rafael J. Wysocki" <rafael@...nel.org> To: Will Deacon <will.deacon@....com> Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, Al Stone <al.stone@...aro.org>, "lenb@...nel.org" <lenb@...nel.org>, Catalin Marinas <Catalin.Marinas@....com>, "robert.moore@...el.com" <robert.moore@...el.com>, "tony.luck@...el.com" <tony.luck@...el.com>, "fenghua.yu@...el.com" <fenghua.yu@...el.com>, "linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, "devel@...ica.org" <devel@...ica.org>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>, "linaro-kernel@...ts.linaro.org" <linaro-kernel@...ts.linaro.org>, "patches@...aro.org" <patches@...aro.org> Subject: Re: [PATCH v3 8/9] ACPI: arm64: use an arch-specific ACPI _OSI method and ACPI blacklist On Thu, Mar 5, 2015 at 11:17 AM, Will Deacon <will.deacon@....com> wrote: > On Wed, Mar 04, 2015 at 11:14:50PM +0000, Rafael J. Wysocki wrote: >> On Monday, March 02, 2015 12:00:21 PM Al Stone wrote: >> > On 03/02/2015 10:29 AM, Will Deacon wrote: >> > > On Wed, Feb 25, 2015 at 12:36:24AM +0000, al.stone@...aro.org wrote: >> > >> diff --git a/arch/arm64/kernel/acpi-blacklist.c b/arch/arm64/kernel/acpi-blacklist.c >> > >> new file mode 100644 >> > >> index 0000000..1be6a56 >> > >> --- /dev/null >> > >> +++ b/arch/arm64/kernel/acpi-blacklist.c >> > >> @@ -0,0 +1,20 @@ >> > >> +/* >> > >> + * ARM64 Specific ACPI Blacklist Support >> > >> + * >> > >> + * Copyright (C) 2015, Linaro Ltd. >> > >> + * Author: Al Stone <al.stone@...aro.org> >> > >> + * >> > >> + * This program is free software; you can redistribute it and/or modify >> > >> + * it under the terms of the GNU General Public License version 2 as >> > >> + * published by the Free Software Foundation. >> > >> + */ >> > >> + >> > >> +#define pr_fmt(fmt) "ACPI: " fmt >> > >> + >> > >> +#include <linux/acpi.h> >> > >> + >> > >> +/* The arm64 ACPI blacklist is currently empty. */ >> > >> +int __init acpi_blacklisted(void) >> > >> +{ >> > >> + return 0; >> > >> +} >> > >> diff --git a/arch/arm64/kernel/acpi-osi.c b/arch/arm64/kernel/acpi-osi.c >> > >> new file mode 100644 >> > >> index 0000000..bb351f4 >> > >> --- /dev/null >> > >> +++ b/arch/arm64/kernel/acpi-osi.c >> > >> @@ -0,0 +1,25 @@ >> > >> +/* >> > >> + * ARM64 Specific ACPI _OSI Support >> > >> + * >> > >> + * Copyright (C) 2015, Linaro Ltd. >> > >> + * Author: Al Stone <al.stone@...aro.org> >> > >> + * >> > >> + * This program is free software; you can redistribute it and/or modify >> > >> + * it under the terms of the GNU General Public License version 2 as >> > >> + * published by the Free Software Foundation. >> > >> + */ >> > >> + >> > >> +#define pr_fmt(fmt) "ACPI: " fmt >> > >> + >> > >> +#include <linux/acpi.h> >> > >> + >> > >> +/* >> > >> + * Consensus is to deprecate _OSI for all new ACPI-supported architectures. >> > >> + * So, for arm64, reduce _OSI to a warning message, and tell the firmware >> > >> + * nothing of value. >> > >> + */ >> > >> +u32 acpi_osi_handler(acpi_string interface, u32 supported) >> > >> +{ >> > >> + pr_warn("_OSI was called, but is deprecated for this architecture.\n"); >> > >> + return false; >> > >> +} >> > > >> > > This kinda feels backwards to me. If _OSI is going away, then the default >> > > should be "the architecture doesn't need to do anything", rather than have >> > > new architectures defining a bunch of empty, useless stub code. >> > > >> > > Anyway we could make this the default in core code and have architectures >> > > that *do* want _OSI override that behaviour, instead of the other way around? >> > > >> > We could do that; I personally don't have a strong preference either way, >> > so I'm inclined to make it whatever structure Rafael thinks is proper since >> > it affects ACPI code most. That being said, the current patch structure >> > made sense to me since it wasn't distorting existing code much -- and given >> > the pure number of x86/ia64 machines vs ARM machines using ACPI, that seemed >> > the more cautious approach. >> > >> > @Rafael: do you have an opinion/preference? >> >> My preference is to avoid changes in the existing code at least for the time >> being. Especially if the changes in question are going to affect ia64, unless >> you have an Itanium machine where you can readily test those, that is. :-) > > Well, this code doesn't even need to compiled for ia64 if we have those > architectures that want to use _OSI select a Kconfig symbol for it, so I > don't think the testing argument is really that valid. I appreciate that you > want to avoid changing the existing code, but I also don't want to add this > sort of stuff to the architecture code, when it really has nothing to do > with the architecture. OK, so consider this. _OSI may be deprecated in the spec for *new* implementations. However, there still are many systems out there that use _OSI and we'll need to support them going forward. So while the spec people may think that they have deprecated _OSI, the reality is that in the kernel it is not going to be deprecated as long as there are systems using it that we need to support. So the whole "_OSI is going away" argument is simply bogus and useless. That aside, yes, we can use a Kconfig symbol to select from x86 and ia64 and compile the generic code conditional on that. That would be fine by me. Rafael -- 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