From: Al Stone <ahs3 at redhat.com>
To: devel@acpica.org
Subject: Re: [Devel] [PATCH 0/7] Start deprecating _OSI on new architectures
Date: Fri, 23 Jan 2015 16:33:00 +0000 [thread overview]
Message-ID: <54C277B4.4090808@redhat.com> (raw)
In-Reply-To: 11226733.uCXYutOZUW@vostro.rjw.lan
[-- Attachment #1: Type: text/plain, Size: 6890 bytes --]
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
> Hi Al,
>
> On Thursday, January 22, 2015 05:44:37 PM al.stone(a)linaro.org wrote:
>> From: Al Stone <al.stone(a)linaro.org>
>>
>> The use of the ACPI _OSI method in Linux has a long and sordid history.
>> Instead of perpetuating past complications on new architectures, the
>> consensus amongst those writing the ACPI specification and those using
>> it seems to be to ultimately deprecate the use of _OSI. I plan to
>> propose such a change to the ACPI specification in the near future.
>>
>> In the meantime, these patches rearrange the implementation of _OSI so
>> that it can be deprecated, or ultimately removed completely, on at least
>> arm64 platforms. This is done by simply moving the functions implementing
>> _OSI to arch-dependent locations. For x86, there should be no change
>> in functionality. For ia64, while it does duplicate some code from x86,
>> there is no longer any connection to the ACPI blacklist code that is only
>> used by x86. For arm64, any use of the _OSI method generates a warning
>> that it has been deprecated, and then always returns false; i.e., that
>> the capability being queried for, whether OS name or functionality, is
>> not supported. This is the first six of the patches.
>
> While I seem to understand the motivation, I don't really like moving code
> around, especially in the ia64 area where we have limited means to test the
> changes. And I hate code duplication pretty much in any form.
I'm not too wild about it either, but it seemed to avoid #ifdefs when I
was trying to think it through.
> Also I don't see anything wrong with sharing code between x86 and ia64 like
> we do today.
Fair enough. That's entirely up to you; the only reason I saw for
separating them was removing the one call to check the blacklist on
ia64. That would have a tiny time savings at boot time, but it is
definitely down in the noise level.
> So, why don't you move the _OSI handling out of osl.c into a separate file
> that will only build if something like CONFIG_ARCH_SPECIFIC_ACPI_OSI is not
> set (and same for blacklist.c). Then, you'll only need to make ARM64
> set CONFIG_ARCH_SPECIFIC_ACPI_OSI and provide the necessary functions
> and you can leave the other architectures alone.
>
> Does that make sense to you?
It does. I'll rewrite these based on that approach. Definitely a lot
less code motion involved...
>> The final patch changes the default value for the _OS_ method for arm64
>> only. Since there is no need to pretend to be older versions of Windows,
>> or any other OS at all, the _OS_ method will return "Linux" on arm64.
>> One can still use the acpi_os_name kernel parameter if there is a need
>> to use some other value.
>>
>> Since we are breaking apart code previously shared, I have tried to make
>> it so that applying the x86 patches alone will continue to compile, at
>> the expense of breaking the build on non-x86 platforms. However, once
>> all of the patches are applied, we should be able to compile on all three
>> architectures. It is best to treat these as one whole.
>>
>> I have only done simple testing with these patches on arm64 and x86 (AMD
>> Seattle and a Lenovo t440s ThinkPad, respectively). Things seem to work
>> as they should once booted, but this is a very, very small sample of
>> possible machines. The ia64 patches cross-compile, but I personally have
>> no way to test them.
>>
>> The arm64 patches also rely on having applied Hanjun's patches for ACPI 5.1
>> on arm64 [0]. The x86 and ia64 parts are not dependent on that patch set,
>> though, and should be usable independently (i.e., patches 1, 3, 4 and 6).
>>
>> NB: some of the patches do not pass checkpatch.pl; the failures I saw were
>> all part of the original code but are only showing up because that code is
>> changing location, so I have left them as is. If necessary, they could be
>> fixed but I was more concerned about the number of changes needed on ia64
>> and not having any way to test them.
>>
>>
>> [0] https://lkml.org/lkml/2015/1/14/586
>>
>>
>> Al Stone (6):
>> ia64: ACPI: move kernel acpi files to a directory
>> arm64: ACPI: move kernel acpi files to a directory
>> x86: ACPI: create arch-dependent version of acpi_osi_handler()
>> ia64: ACPI: create arch-dependent version of acpi_osi_handler()
>> arm64: ACPI: create arch-dependent version of acpi_osi_handler()
>> x86: ia64: arm64: ACPI: move _OSI support functions to arch-dependent
>> locations
>>
>> Hanjun Guo (1):
>> ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64
>>
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/acpi.c | 359 --------------
>> arch/arm64/kernel/acpi/Makefile | 1 +
>> arch/arm64/kernel/acpi/acpi.c | 359 ++++++++++++++
>> arch/arm64/kernel/acpi/osi.c | 26 +
>> arch/ia64/kernel/Makefile | 2 +-
>> arch/ia64/kernel/acpi-ext.c | 104 ----
>> arch/ia64/kernel/acpi.c | 1000 --------------------------------------
>> arch/ia64/kernel/acpi/Makefile | 1 +
>> arch/ia64/kernel/acpi/acpi-ext.c | 104 ++++
>> arch/ia64/kernel/acpi/acpi.c | 1000 ++++++++++++++++++++++++++++++++++++++
>> arch/ia64/kernel/acpi/osi.c | 119 +++++
>> arch/x86/kernel/acpi/Makefile | 2 +-
>> arch/x86/kernel/acpi/blacklist.c | 327 +++++++++++++
>> arch/x86/kernel/acpi/boot.c | 5 +-
>> arch/x86/kernel/acpi/osi.c | 255 ++++++++++
>> drivers/acpi/Kconfig | 8 +
>> drivers/acpi/Makefile | 1 -
>> drivers/acpi/blacklist.c | 323 ------------
>> drivers/acpi/osl.c | 217 ---------
>> include/acpi/acconfig.h | 2 +
>> include/acpi/platform/aclinux.h | 4 +
>> include/linux/acpi.h | 4 +-
>> 24 files changed, 2215 insertions(+), 2011 deletions(-)
>> delete mode 100644 arch/arm64/kernel/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/Makefile
>> create mode 100644 arch/arm64/kernel/acpi/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/osi.c
>> delete mode 100644 arch/ia64/kernel/acpi-ext.c
>> delete mode 100644 arch/ia64/kernel/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/Makefile
>> create mode 100644 arch/ia64/kernel/acpi/acpi-ext.c
>> create mode 100644 arch/ia64/kernel/acpi/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/osi.c
>> create mode 100644 arch/x86/kernel/acpi/blacklist.c
>> create mode 100644 arch/x86/kernel/acpi/osi.c
>> delete mode 100644 drivers/acpi/blacklist.c
>>
>>
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3(a)redhat.com
-----------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <ahs3@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, al.stone@linaro.org
Cc: tony.luck@intel.com, fenghua.yu@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, lenb@kernel.org,
robert.moore@intel.com, linux-ia64@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devel@acpica.org,
linaro-acpi@lists.linaro.org, linaro-kernel@lists.linaro.org,
patches@linaro.org
Subject: Re: [PATCH 0/7] Start deprecating _OSI on new architectures
Date: Fri, 23 Jan 2015 09:32:52 -0700 [thread overview]
Message-ID: <54C277B4.4090808@redhat.com> (raw)
In-Reply-To: <11226733.uCXYutOZUW@vostro.rjw.lan>
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
> Hi Al,
>
> On Thursday, January 22, 2015 05:44:37 PM al.stone@linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> The use of the ACPI _OSI method in Linux has a long and sordid history.
>> Instead of perpetuating past complications on new architectures, the
>> consensus amongst those writing the ACPI specification and those using
>> it seems to be to ultimately deprecate the use of _OSI. I plan to
>> propose such a change to the ACPI specification in the near future.
>>
>> In the meantime, these patches rearrange the implementation of _OSI so
>> that it can be deprecated, or ultimately removed completely, on at least
>> arm64 platforms. This is done by simply moving the functions implementing
>> _OSI to arch-dependent locations. For x86, there should be no change
>> in functionality. For ia64, while it does duplicate some code from x86,
>> there is no longer any connection to the ACPI blacklist code that is only
>> used by x86. For arm64, any use of the _OSI method generates a warning
>> that it has been deprecated, and then always returns false; i.e., that
>> the capability being queried for, whether OS name or functionality, is
>> not supported. This is the first six of the patches.
>
> While I seem to understand the motivation, I don't really like moving code
> around, especially in the ia64 area where we have limited means to test the
> changes. And I hate code duplication pretty much in any form.
I'm not too wild about it either, but it seemed to avoid #ifdefs when I
was trying to think it through.
> Also I don't see anything wrong with sharing code between x86 and ia64 like
> we do today.
Fair enough. That's entirely up to you; the only reason I saw for
separating them was removing the one call to check the blacklist on
ia64. That would have a tiny time savings at boot time, but it is
definitely down in the noise level.
> So, why don't you move the _OSI handling out of osl.c into a separate file
> that will only build if something like CONFIG_ARCH_SPECIFIC_ACPI_OSI is not
> set (and same for blacklist.c). Then, you'll only need to make ARM64
> set CONFIG_ARCH_SPECIFIC_ACPI_OSI and provide the necessary functions
> and you can leave the other architectures alone.
>
> Does that make sense to you?
It does. I'll rewrite these based on that approach. Definitely a lot
less code motion involved...
>> The final patch changes the default value for the _OS_ method for arm64
>> only. Since there is no need to pretend to be older versions of Windows,
>> or any other OS at all, the _OS_ method will return "Linux" on arm64.
>> One can still use the acpi_os_name kernel parameter if there is a need
>> to use some other value.
>>
>> Since we are breaking apart code previously shared, I have tried to make
>> it so that applying the x86 patches alone will continue to compile, at
>> the expense of breaking the build on non-x86 platforms. However, once
>> all of the patches are applied, we should be able to compile on all three
>> architectures. It is best to treat these as one whole.
>>
>> I have only done simple testing with these patches on arm64 and x86 (AMD
>> Seattle and a Lenovo t440s ThinkPad, respectively). Things seem to work
>> as they should once booted, but this is a very, very small sample of
>> possible machines. The ia64 patches cross-compile, but I personally have
>> no way to test them.
>>
>> The arm64 patches also rely on having applied Hanjun's patches for ACPI 5.1
>> on arm64 [0]. The x86 and ia64 parts are not dependent on that patch set,
>> though, and should be usable independently (i.e., patches 1, 3, 4 and 6).
>>
>> NB: some of the patches do not pass checkpatch.pl; the failures I saw were
>> all part of the original code but are only showing up because that code is
>> changing location, so I have left them as is. If necessary, they could be
>> fixed but I was more concerned about the number of changes needed on ia64
>> and not having any way to test them.
>>
>>
>> [0] https://lkml.org/lkml/2015/1/14/586
>>
>>
>> Al Stone (6):
>> ia64: ACPI: move kernel acpi files to a directory
>> arm64: ACPI: move kernel acpi files to a directory
>> x86: ACPI: create arch-dependent version of acpi_osi_handler()
>> ia64: ACPI: create arch-dependent version of acpi_osi_handler()
>> arm64: ACPI: create arch-dependent version of acpi_osi_handler()
>> x86: ia64: arm64: ACPI: move _OSI support functions to arch-dependent
>> locations
>>
>> Hanjun Guo (1):
>> ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64
>>
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/acpi.c | 359 --------------
>> arch/arm64/kernel/acpi/Makefile | 1 +
>> arch/arm64/kernel/acpi/acpi.c | 359 ++++++++++++++
>> arch/arm64/kernel/acpi/osi.c | 26 +
>> arch/ia64/kernel/Makefile | 2 +-
>> arch/ia64/kernel/acpi-ext.c | 104 ----
>> arch/ia64/kernel/acpi.c | 1000 --------------------------------------
>> arch/ia64/kernel/acpi/Makefile | 1 +
>> arch/ia64/kernel/acpi/acpi-ext.c | 104 ++++
>> arch/ia64/kernel/acpi/acpi.c | 1000 ++++++++++++++++++++++++++++++++++++++
>> arch/ia64/kernel/acpi/osi.c | 119 +++++
>> arch/x86/kernel/acpi/Makefile | 2 +-
>> arch/x86/kernel/acpi/blacklist.c | 327 +++++++++++++
>> arch/x86/kernel/acpi/boot.c | 5 +-
>> arch/x86/kernel/acpi/osi.c | 255 ++++++++++
>> drivers/acpi/Kconfig | 8 +
>> drivers/acpi/Makefile | 1 -
>> drivers/acpi/blacklist.c | 323 ------------
>> drivers/acpi/osl.c | 217 ---------
>> include/acpi/acconfig.h | 2 +
>> include/acpi/platform/aclinux.h | 4 +
>> include/linux/acpi.h | 4 +-
>> 24 files changed, 2215 insertions(+), 2011 deletions(-)
>> delete mode 100644 arch/arm64/kernel/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/Makefile
>> create mode 100644 arch/arm64/kernel/acpi/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/osi.c
>> delete mode 100644 arch/ia64/kernel/acpi-ext.c
>> delete mode 100644 arch/ia64/kernel/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/Makefile
>> create mode 100644 arch/ia64/kernel/acpi/acpi-ext.c
>> create mode 100644 arch/ia64/kernel/acpi/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/osi.c
>> create mode 100644 arch/x86/kernel/acpi/blacklist.c
>> create mode 100644 arch/x86/kernel/acpi/osi.c
>> delete mode 100644 drivers/acpi/blacklist.c
>>
>>
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: Al Stone <ahs3@redhat.com>
To: "Rafael J. Wysocki" <rjw@rjwysocki.net>, al.stone@linaro.org
Cc: tony.luck@intel.com, fenghua.yu@intel.com,
catalin.marinas@arm.com, will.deacon@arm.com, tglx@linutronix.de,
mingo@redhat.com, hpa@zytor.com, lenb@kernel.org,
robert.moore@intel.com, linux-ia64@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devel@acpica.org,
linaro-acpi@lists.linaro.org, linaro-kernel@lists.linaro.org,
patches@linaro.org
Subject: Re: [PATCH 0/7] Start deprecating _OSI on new architectures
Date: Fri, 23 Jan 2015 16:32:52 +0000 [thread overview]
Message-ID: <54C277B4.4090808@redhat.com> (raw)
In-Reply-To: <11226733.uCXYutOZUW@vostro.rjw.lan>
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
> Hi Al,
>
> On Thursday, January 22, 2015 05:44:37 PM al.stone@linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> The use of the ACPI _OSI method in Linux has a long and sordid history.
>> Instead of perpetuating past complications on new architectures, the
>> consensus amongst those writing the ACPI specification and those using
>> it seems to be to ultimately deprecate the use of _OSI. I plan to
>> propose such a change to the ACPI specification in the near future.
>>
>> In the meantime, these patches rearrange the implementation of _OSI so
>> that it can be deprecated, or ultimately removed completely, on at least
>> arm64 platforms. This is done by simply moving the functions implementing
>> _OSI to arch-dependent locations. For x86, there should be no change
>> in functionality. For ia64, while it does duplicate some code from x86,
>> there is no longer any connection to the ACPI blacklist code that is only
>> used by x86. For arm64, any use of the _OSI method generates a warning
>> that it has been deprecated, and then always returns false; i.e., that
>> the capability being queried for, whether OS name or functionality, is
>> not supported. This is the first six of the patches.
>
> While I seem to understand the motivation, I don't really like moving code
> around, especially in the ia64 area where we have limited means to test the
> changes. And I hate code duplication pretty much in any form.
I'm not too wild about it either, but it seemed to avoid #ifdefs when I
was trying to think it through.
> Also I don't see anything wrong with sharing code between x86 and ia64 like
> we do today.
Fair enough. That's entirely up to you; the only reason I saw for
separating them was removing the one call to check the blacklist on
ia64. That would have a tiny time savings at boot time, but it is
definitely down in the noise level.
> So, why don't you move the _OSI handling out of osl.c into a separate file
> that will only build if something like CONFIG_ARCH_SPECIFIC_ACPI_OSI is not
> set (and same for blacklist.c). Then, you'll only need to make ARM64
> set CONFIG_ARCH_SPECIFIC_ACPI_OSI and provide the necessary functions
> and you can leave the other architectures alone.
>
> Does that make sense to you?
It does. I'll rewrite these based on that approach. Definitely a lot
less code motion involved...
>> The final patch changes the default value for the _OS_ method for arm64
>> only. Since there is no need to pretend to be older versions of Windows,
>> or any other OS at all, the _OS_ method will return "Linux" on arm64.
>> One can still use the acpi_os_name kernel parameter if there is a need
>> to use some other value.
>>
>> Since we are breaking apart code previously shared, I have tried to make
>> it so that applying the x86 patches alone will continue to compile, at
>> the expense of breaking the build on non-x86 platforms. However, once
>> all of the patches are applied, we should be able to compile on all three
>> architectures. It is best to treat these as one whole.
>>
>> I have only done simple testing with these patches on arm64 and x86 (AMD
>> Seattle and a Lenovo t440s ThinkPad, respectively). Things seem to work
>> as they should once booted, but this is a very, very small sample of
>> possible machines. The ia64 patches cross-compile, but I personally have
>> no way to test them.
>>
>> The arm64 patches also rely on having applied Hanjun's patches for ACPI 5.1
>> on arm64 [0]. The x86 and ia64 parts are not dependent on that patch set,
>> though, and should be usable independently (i.e., patches 1, 3, 4 and 6).
>>
>> NB: some of the patches do not pass checkpatch.pl; the failures I saw were
>> all part of the original code but are only showing up because that code is
>> changing location, so I have left them as is. If necessary, they could be
>> fixed but I was more concerned about the number of changes needed on ia64
>> and not having any way to test them.
>>
>>
>> [0] https://lkml.org/lkml/2015/1/14/586
>>
>>
>> Al Stone (6):
>> ia64: ACPI: move kernel acpi files to a directory
>> arm64: ACPI: move kernel acpi files to a directory
>> x86: ACPI: create arch-dependent version of acpi_osi_handler()
>> ia64: ACPI: create arch-dependent version of acpi_osi_handler()
>> arm64: ACPI: create arch-dependent version of acpi_osi_handler()
>> x86: ia64: arm64: ACPI: move _OSI support functions to arch-dependent
>> locations
>>
>> Hanjun Guo (1):
>> ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64
>>
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/acpi.c | 359 --------------
>> arch/arm64/kernel/acpi/Makefile | 1 +
>> arch/arm64/kernel/acpi/acpi.c | 359 ++++++++++++++
>> arch/arm64/kernel/acpi/osi.c | 26 +
>> arch/ia64/kernel/Makefile | 2 +-
>> arch/ia64/kernel/acpi-ext.c | 104 ----
>> arch/ia64/kernel/acpi.c | 1000 --------------------------------------
>> arch/ia64/kernel/acpi/Makefile | 1 +
>> arch/ia64/kernel/acpi/acpi-ext.c | 104 ++++
>> arch/ia64/kernel/acpi/acpi.c | 1000 ++++++++++++++++++++++++++++++++++++++
>> arch/ia64/kernel/acpi/osi.c | 119 +++++
>> arch/x86/kernel/acpi/Makefile | 2 +-
>> arch/x86/kernel/acpi/blacklist.c | 327 +++++++++++++
>> arch/x86/kernel/acpi/boot.c | 5 +-
>> arch/x86/kernel/acpi/osi.c | 255 ++++++++++
>> drivers/acpi/Kconfig | 8 +
>> drivers/acpi/Makefile | 1 -
>> drivers/acpi/blacklist.c | 323 ------------
>> drivers/acpi/osl.c | 217 ---------
>> include/acpi/acconfig.h | 2 +
>> include/acpi/platform/aclinux.h | 4 +
>> include/linux/acpi.h | 4 +-
>> 24 files changed, 2215 insertions(+), 2011 deletions(-)
>> delete mode 100644 arch/arm64/kernel/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/Makefile
>> create mode 100644 arch/arm64/kernel/acpi/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/osi.c
>> delete mode 100644 arch/ia64/kernel/acpi-ext.c
>> delete mode 100644 arch/ia64/kernel/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/Makefile
>> create mode 100644 arch/ia64/kernel/acpi/acpi-ext.c
>> create mode 100644 arch/ia64/kernel/acpi/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/osi.c
>> create mode 100644 arch/x86/kernel/acpi/blacklist.c
>> create mode 100644 arch/x86/kernel/acpi/osi.c
>> delete mode 100644 drivers/acpi/blacklist.c
>>
>>
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3@redhat.com
-----------------------------------
WARNING: multiple messages have this Message-ID (diff)
From: ahs3@redhat.com (Al Stone)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/7] Start deprecating _OSI on new architectures
Date: Fri, 23 Jan 2015 09:32:52 -0700 [thread overview]
Message-ID: <54C277B4.4090808@redhat.com> (raw)
In-Reply-To: <11226733.uCXYutOZUW@vostro.rjw.lan>
On 01/23/2015 08:43 AM, Rafael J. Wysocki wrote:
> Hi Al,
>
> On Thursday, January 22, 2015 05:44:37 PM al.stone at linaro.org wrote:
>> From: Al Stone <al.stone@linaro.org>
>>
>> The use of the ACPI _OSI method in Linux has a long and sordid history.
>> Instead of perpetuating past complications on new architectures, the
>> consensus amongst those writing the ACPI specification and those using
>> it seems to be to ultimately deprecate the use of _OSI. I plan to
>> propose such a change to the ACPI specification in the near future.
>>
>> In the meantime, these patches rearrange the implementation of _OSI so
>> that it can be deprecated, or ultimately removed completely, on at least
>> arm64 platforms. This is done by simply moving the functions implementing
>> _OSI to arch-dependent locations. For x86, there should be no change
>> in functionality. For ia64, while it does duplicate some code from x86,
>> there is no longer any connection to the ACPI blacklist code that is only
>> used by x86. For arm64, any use of the _OSI method generates a warning
>> that it has been deprecated, and then always returns false; i.e., that
>> the capability being queried for, whether OS name or functionality, is
>> not supported. This is the first six of the patches.
>
> While I seem to understand the motivation, I don't really like moving code
> around, especially in the ia64 area where we have limited means to test the
> changes. And I hate code duplication pretty much in any form.
I'm not too wild about it either, but it seemed to avoid #ifdefs when I
was trying to think it through.
> Also I don't see anything wrong with sharing code between x86 and ia64 like
> we do today.
Fair enough. That's entirely up to you; the only reason I saw for
separating them was removing the one call to check the blacklist on
ia64. That would have a tiny time savings at boot time, but it is
definitely down in the noise level.
> So, why don't you move the _OSI handling out of osl.c into a separate file
> that will only build if something like CONFIG_ARCH_SPECIFIC_ACPI_OSI is not
> set (and same for blacklist.c). Then, you'll only need to make ARM64
> set CONFIG_ARCH_SPECIFIC_ACPI_OSI and provide the necessary functions
> and you can leave the other architectures alone.
>
> Does that make sense to you?
It does. I'll rewrite these based on that approach. Definitely a lot
less code motion involved...
>> The final patch changes the default value for the _OS_ method for arm64
>> only. Since there is no need to pretend to be older versions of Windows,
>> or any other OS at all, the _OS_ method will return "Linux" on arm64.
>> One can still use the acpi_os_name kernel parameter if there is a need
>> to use some other value.
>>
>> Since we are breaking apart code previously shared, I have tried to make
>> it so that applying the x86 patches alone will continue to compile, at
>> the expense of breaking the build on non-x86 platforms. However, once
>> all of the patches are applied, we should be able to compile on all three
>> architectures. It is best to treat these as one whole.
>>
>> I have only done simple testing with these patches on arm64 and x86 (AMD
>> Seattle and a Lenovo t440s ThinkPad, respectively). Things seem to work
>> as they should once booted, but this is a very, very small sample of
>> possible machines. The ia64 patches cross-compile, but I personally have
>> no way to test them.
>>
>> The arm64 patches also rely on having applied Hanjun's patches for ACPI 5.1
>> on arm64 [0]. The x86 and ia64 parts are not dependent on that patch set,
>> though, and should be usable independently (i.e., patches 1, 3, 4 and 6).
>>
>> NB: some of the patches do not pass checkpatch.pl; the failures I saw were
>> all part of the original code but are only showing up because that code is
>> changing location, so I have left them as is. If necessary, they could be
>> fixed but I was more concerned about the number of changes needed on ia64
>> and not having any way to test them.
>>
>>
>> [0] https://lkml.org/lkml/2015/1/14/586
>>
>>
>> Al Stone (6):
>> ia64: ACPI: move kernel acpi files to a directory
>> arm64: ACPI: move kernel acpi files to a directory
>> x86: ACPI: create arch-dependent version of acpi_osi_handler()
>> ia64: ACPI: create arch-dependent version of acpi_osi_handler()
>> arm64: ACPI: create arch-dependent version of acpi_osi_handler()
>> x86: ia64: arm64: ACPI: move _OSI support functions to arch-dependent
>> locations
>>
>> Hanjun Guo (1):
>> ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64
>>
>> arch/arm64/Kconfig | 1 +
>> arch/arm64/kernel/Makefile | 2 +-
>> arch/arm64/kernel/acpi.c | 359 --------------
>> arch/arm64/kernel/acpi/Makefile | 1 +
>> arch/arm64/kernel/acpi/acpi.c | 359 ++++++++++++++
>> arch/arm64/kernel/acpi/osi.c | 26 +
>> arch/ia64/kernel/Makefile | 2 +-
>> arch/ia64/kernel/acpi-ext.c | 104 ----
>> arch/ia64/kernel/acpi.c | 1000 --------------------------------------
>> arch/ia64/kernel/acpi/Makefile | 1 +
>> arch/ia64/kernel/acpi/acpi-ext.c | 104 ++++
>> arch/ia64/kernel/acpi/acpi.c | 1000 ++++++++++++++++++++++++++++++++++++++
>> arch/ia64/kernel/acpi/osi.c | 119 +++++
>> arch/x86/kernel/acpi/Makefile | 2 +-
>> arch/x86/kernel/acpi/blacklist.c | 327 +++++++++++++
>> arch/x86/kernel/acpi/boot.c | 5 +-
>> arch/x86/kernel/acpi/osi.c | 255 ++++++++++
>> drivers/acpi/Kconfig | 8 +
>> drivers/acpi/Makefile | 1 -
>> drivers/acpi/blacklist.c | 323 ------------
>> drivers/acpi/osl.c | 217 ---------
>> include/acpi/acconfig.h | 2 +
>> include/acpi/platform/aclinux.h | 4 +
>> include/linux/acpi.h | 4 +-
>> 24 files changed, 2215 insertions(+), 2011 deletions(-)
>> delete mode 100644 arch/arm64/kernel/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/Makefile
>> create mode 100644 arch/arm64/kernel/acpi/acpi.c
>> create mode 100644 arch/arm64/kernel/acpi/osi.c
>> delete mode 100644 arch/ia64/kernel/acpi-ext.c
>> delete mode 100644 arch/ia64/kernel/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/Makefile
>> create mode 100644 arch/ia64/kernel/acpi/acpi-ext.c
>> create mode 100644 arch/ia64/kernel/acpi/acpi.c
>> create mode 100644 arch/ia64/kernel/acpi/osi.c
>> create mode 100644 arch/x86/kernel/acpi/blacklist.c
>> create mode 100644 arch/x86/kernel/acpi/osi.c
>> delete mode 100644 drivers/acpi/blacklist.c
>>
>>
>
--
ciao,
al
-----------------------------------
Al Stone
Software Engineer
Red Hat, Inc.
ahs3 at redhat.com
-----------------------------------
next prev reply other threads:[~2015-01-23 16:33 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 0:44 [PATCH 0/7] Start deprecating _OSI on new architectures al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 1/7] ia64: ACPI: move kernel acpi files to a directory al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:49 ` Al Stone
2015-01-23 0:49 ` Al Stone
2015-01-23 0:49 ` Al Stone
2015-01-23 0:44 ` [PATCH 2/7] arm64: " al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 3/7] x86: ACPI: create arch-dependent version of acpi_osi_handler() al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 4/7] ia64: " al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 5/7] arm64: " al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 6/7] x86: ia64: arm64: ACPI: move _OSI support functions to arch-dependent locations al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 0:44 ` [PATCH 7/7] ACPI: use Linux as ACPI_OS_NAME for _OS on ARM64 al.stone
2015-01-23 0:44 ` al.stone at linaro.org
2015-01-23 0:44 ` al.stone
2015-01-23 15:55 ` Rafael J. Wysocki
2015-01-23 15:55 ` Rafael J. Wysocki
2015-01-23 15:55 ` Rafael J. Wysocki
2015-01-23 16:34 ` Al Stone
2015-01-23 16:34 ` [Devel] " Al Stone
2015-01-23 16:34 ` Al Stone
2015-01-23 16:34 ` Al Stone
2015-01-23 15:43 ` [PATCH 0/7] Start deprecating _OSI on new architectures Rafael J. Wysocki
2015-01-23 15:43 ` Rafael J. Wysocki
2015-01-23 15:43 ` Rafael J. Wysocki
2015-01-23 16:32 ` Al Stone [this message]
2015-01-23 16:33 ` [Devel] " Al Stone
2015-01-23 16:32 ` Al Stone
2015-01-23 16:32 ` Al Stone
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C277B4.4090808@redhat.com \
--to=devel@acpica.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.