| Message ID | 1424824585-6405-9-git-send-email-al.stone@linaro.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Al, On Wed, Feb 25, 2015 at 12:36:24AM +0000, al.stone@linaro.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@linaro.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@linaro.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? Cheers, Will
On 03/02/2015 10:29 AM, Will Deacon wrote: > Hi Al, > > On Wed, Feb 25, 2015 at 12:36:24AM +0000, al.stone@linaro.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@linaro.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@linaro.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? > > Cheers, > > Will > 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?
On Monday, March 02, 2015 12:00:21 PM Al Stone wrote: > On 03/02/2015 10:29 AM, Will Deacon wrote: > > Hi Al, > > > > On Wed, Feb 25, 2015 at 12:36:24AM +0000, al.stone@linaro.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@linaro.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@linaro.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? > > > > Cheers, > > > > Will > > > > 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. :-)
On Tuesday, February 24, 2015 05:36:24 PM al.stone@linaro.org wrote: > From: Al Stone <al.stone@linaro.org> > > Now that all of the _OSI functionality has been separated out, we can > provide arch-specific functionality for it. This also allows us to do > the same for the acpi_blacklisted() function. We also make sure the > defaults for the arm64 kernel are set so that the arch-specific _OSI > method and blacklist are always used for ACPI. > > For arm64, any use of _OSI will issue a warning that it is deprecated. > All use of _OSI will return false -- i.e., it will return no useful > information to any firmware using it. The ability to temporarily turn > on _OSI, or turn off _OSI, or affect it in other ways from the command > line is no longer available for arm64, either. The blacklist for ACPI > on arm64 is empty. This will, of course, require ACPI to be enabled > for arm64. > > Signed-off-by: Al Stone <al.stone@linaro.org> > --- > arch/arm64/Kconfig | 1 + > arch/arm64/kernel/Makefile | 2 +- > arch/arm64/kernel/acpi-blacklist.c | 20 ++++++++++++++++++++ > arch/arm64/kernel/acpi-osi.c | 25 +++++++++++++++++++++++++ > 4 files changed, 47 insertions(+), 1 deletion(-) > create mode 100644 arch/arm64/kernel/acpi-blacklist.c > create mode 100644 arch/arm64/kernel/acpi-osi.c > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index 3f08727..e441d28 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -7,6 +7,7 @@ config ARM64 > select ARCH_HAS_SG_CHAIN > select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST > select ARCH_USE_CMPXCHG_LOCKREF > + select ARCH_SPECIFIC_ACPI_OSI if ACPI > select ARCH_SUPPORTS_ATOMIC_RMW > select ARCH_WANT_OPTIONAL_GPIOLIB > select ARCH_WANT_COMPAT_IPC_PARSE_VERSION > diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile > index 79bdd3b..b5e1268 100644 > --- a/arch/arm64/kernel/Makefile > +++ b/arch/arm64/kernel/Makefile > @@ -35,7 +35,7 @@ arm64-obj-$(CONFIG_KGDB) += kgdb.o > arm64-obj-$(CONFIG_EFI) += efi.o efi-stub.o efi-entry.o > arm64-obj-$(CONFIG_PCI) += pci.o > arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o > -arm64-obj-$(CONFIG_ACPI) += acpi.o > +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi-osi.o acpi-blacklist.o > > obj-y += $(arm64-obj-y) vdso/ > obj-m += $(arm64-obj-m) > 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@linaro.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@linaro.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"); I'd prefer "ACPI _OSI is not implemented for this architecture". > + return false; > +} >
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@linaro.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@linaro.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@linaro.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. Will
On Thu, Mar 5, 2015 at 11:17 AM, Will Deacon <will.deacon@arm.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@linaro.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@linaro.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@linaro.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
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index 3f08727..e441d28 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -7,6 +7,7 @@ config ARM64 select ARCH_HAS_SG_CHAIN select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST select ARCH_USE_CMPXCHG_LOCKREF + select ARCH_SPECIFIC_ACPI_OSI if ACPI select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_WANT_OPTIONAL_GPIOLIB select ARCH_WANT_COMPAT_IPC_PARSE_VERSION diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile index 79bdd3b..b5e1268 100644 --- a/arch/arm64/kernel/Makefile +++ b/arch/arm64/kernel/Makefile @@ -35,7 +35,7 @@ arm64-obj-$(CONFIG_KGDB) += kgdb.o arm64-obj-$(CONFIG_EFI) += efi.o efi-stub.o efi-entry.o arm64-obj-$(CONFIG_PCI) += pci.o arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o -arm64-obj-$(CONFIG_ACPI) += acpi.o +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi-osi.o acpi-blacklist.o obj-y += $(arm64-obj-y) vdso/ obj-m += $(arm64-obj-m) 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@linaro.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@linaro.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; +}