In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. As ACPI always uses I/O port access we depend on
HAS_IOPORT unconditionally.
Co-developed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
---
drivers/acpi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index cdbdf68bd98f..b57f15817ede 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
menuconfig ACPI
bool "ACPI (Advanced Configuration and Power Interface) Support"
depends on ARCH_SUPPORTS_ACPI
+ depends on HAS_IOPORT
select PNP
select NLS
default y if X86
--
2.32.0
On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
>
> In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> not being declared. As ACPI always uses I/O port access
The ARM64 people may not agree with this.
> we depend on HAS_IOPORT unconditionally.
>
> Co-developed-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Arnd Bergmann <[email protected]>
> Signed-off-by: Niklas Schnelle <[email protected]>
> ---
> drivers/acpi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index cdbdf68bd98f..b57f15817ede 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> menuconfig ACPI
> bool "ACPI (Advanced Configuration and Power Interface) Support"
> depends on ARCH_SUPPORTS_ACPI
> + depends on HAS_IOPORT
> select PNP
> select NLS
> default y if X86
> --
> 2.32.0
>
On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > not being declared. As ACPI always uses I/O port access
>
> The ARM64 people may not agree with this.
Maybe my wording is bad. This is my rewording of what Arnd had in his
original mail: "The ACPI subsystem needs access to I/O ports, so that
also gets a dependency."(
https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
).
>
> > we depend on HAS_IOPORT unconditionally.
> >
> > Co-developed-by: Arnd Bergmann <[email protected]>
> > Signed-off-by: Arnd Bergmann <[email protected]>
> > Signed-off-by: Niklas Schnelle <[email protected]>
> > ---
> > drivers/acpi/Kconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > index cdbdf68bd98f..b57f15817ede 100644
> > --- a/drivers/acpi/Kconfig
> > +++ b/drivers/acpi/Kconfig
> > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > menuconfig ACPI
> > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > depends on ARCH_SUPPORTS_ACPI
> > + depends on HAS_IOPORT
> > select PNP
> > select NLS
> > default y if X86
> > --
> > 2.32.0
> >
On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <[email protected]> wrote:
>
> On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > not being declared. As ACPI always uses I/O port access
> >
> > The ARM64 people may not agree with this.
>
> Maybe my wording is bad. This is my rewording of what Arnd had in his
> original mail: "The ACPI subsystem needs access to I/O ports, so that
> also gets a dependency."(
> https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> ).
And my point is that on ARM64 the ACPI subsystem does not need to
access IO ports.
It may not even need to access them on x86, but that depends on the
platform firmware in use.
If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
applies to ia64 too)?
> >
> > > we depend on HAS_IOPORT unconditionally.
> > >
> > > Co-developed-by: Arnd Bergmann <[email protected]>
> > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > Signed-off-by: Niklas Schnelle <[email protected]>
> > > ---
> > > drivers/acpi/Kconfig | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > index cdbdf68bd98f..b57f15817ede 100644
> > > --- a/drivers/acpi/Kconfig
> > > +++ b/drivers/acpi/Kconfig
> > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > menuconfig ACPI
> > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > depends on ARCH_SUPPORTS_ACPI
> > > + depends on HAS_IOPORT
> > > select PNP
> > > select NLS
> > > default y if X86
> > > --
> > > 2.32.0
> > >
>
On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <[email protected]> wrote:
>
> On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <[email protected]> wrote:
> >
> > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > not being declared. As ACPI always uses I/O port access
> > >
> > > The ARM64 people may not agree with this.
> >
> > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > also gets a dependency."(
> > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > ).
>
> And my point is that on ARM64 the ACPI subsystem does not need to
> access IO ports.
>
> It may not even need to access them on x86, but that depends on the
> platform firmware in use.
>
> If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> applies to ia64 too)?
>
> > >
> > > > we depend on HAS_IOPORT unconditionally.
> > > >
> > > > Co-developed-by: Arnd Bergmann <[email protected]>
> > > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > > Signed-off-by: Niklas Schnelle <[email protected]>
> > > > ---
> > > > drivers/acpi/Kconfig | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > --- a/drivers/acpi/Kconfig
> > > > +++ b/drivers/acpi/Kconfig
> > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > menuconfig ACPI
> > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > depends on ARCH_SUPPORTS_ACPI
Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> > > > + depends on HAS_IOPORT
> > > > select PNP
> > > > select NLS
> > > > default y if X86
> > > > --
> > > > 2.32.0
> > > >
> >
On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <[email protected]> wrote:
> > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <[email protected]> wrote:
> > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > not being declared. As ACPI always uses I/O port access
> > > >
> > > > The ARM64 people may not agree with this.
> > >
> > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > also gets a dependency."(
> > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > ).
> >
> > And my point is that on ARM64 the ACPI subsystem does not need to
> > access IO ports.
> >
> > It may not even need to access them on x86, but that depends on the
> > platform firmware in use.
Well at least it does compile code calling outb() in
drivers/acpi/ec.c:acpi_ec_write_cmd(). Not sure if there is an
alternative path at runtime if there is then we might want to instead
use ifdefs to always use the non I/O port path if HAS_IOPORT is
undefined.
> >
> > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > applies to ia64 too)?
Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
all select HAS_IOPORT too. See patch 02 or the summary in the cover
letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
hexagon, csky, and xtensa do not select it.
> >
> > > > > we depend on HAS_IOPORT unconditionally.
> > > > >
> > > > > Co-developed-by: Arnd Bergmann <[email protected]>
> > > > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > > > Signed-off-by: Niklas Schnelle <[email protected]>
> > > > > ---
> > > > > drivers/acpi/Kconfig | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > --- a/drivers/acpi/Kconfig
> > > > > +++ b/drivers/acpi/Kconfig
> > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > menuconfig ACPI
> > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > depends on ARCH_SUPPORTS_ACPI
>
> Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
If you prefer to have the dependency there that should work too yes.
>
> > > > > + depends on HAS_IOPORT
> > > > > select PNP
> > > > > select NLS
> > > > > default y if X86
> > > > > --
> > > > > 2.32.0
> > > > >
On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <[email protected]> wrote:
>
> On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <[email protected]> wrote:
> > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <[email protected]> wrote:
> > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > not being declared. As ACPI always uses I/O port access
> > > > >
> > > > > The ARM64 people may not agree with this.
> > > >
> > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > also gets a dependency."(
> > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > ).
> > >
> > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > access IO ports.
> > >
> > > It may not even need to access them on x86, but that depends on the
> > > platform firmware in use.
>
> Well at least it does compile code calling outb() in
> drivers/acpi/ec.c:acpi_ec_write_cmd().
That's the EC driver which is not used on arm64 AFAICS and that driver
itself can be made depend on HAS_IOPORT.
> Not sure if there is an
> alternative path at runtime if there is then we might want to instead
> use ifdefs to always use the non I/O port path if HAS_IOPORT is
> undefined.
>
> > >
> > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > applies to ia64 too)?
>
> Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> all select HAS_IOPORT too. See patch 02 or the summary in the cover
> letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> hexagon, csky, and xtensa do not select it.
If that is the case, there should be no need to add the extra
dependency to CONFIG_ACPI.
> > >
> > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > >
> > > > > > Co-developed-by: Arnd Bergmann <[email protected]>
> > > > > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > > > > Signed-off-by: Niklas Schnelle <[email protected]>
> > > > > > ---
> > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > 1 file changed, 1 insertion(+)
> > > > > >
> > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > --- a/drivers/acpi/Kconfig
> > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > menuconfig ACPI
> > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > depends on ARCH_SUPPORTS_ACPI
> >
> > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
>
> If you prefer to have the dependency there that should work too yes.
I would prefer that.
IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
should be met.
On Tue, 2021-12-28 at 16:20 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <[email protected]> wrote:
> > On Mon, 2021-12-27 at 18:15 +0100, Rafael J. Wysocki wrote:
> > > On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <[email protected]> wrote:
> > > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <[email protected]> wrote:
> > > > > On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> > > > > > On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <[email protected]> wrote:
> > > > > > > In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
> > > > > > > not being declared. As ACPI always uses I/O port access
> > > > > >
> > > > > > The ARM64 people may not agree with this.
> > > > >
> > > > > Maybe my wording is bad. This is my rewording of what Arnd had in his
> > > > > original mail: "The ACPI subsystem needs access to I/O ports, so that
> > > > > also gets a dependency."(
> > > > > https://lore.kernel.org/lkml/CAK8P3a0MNbx-iuzW_-=0ab6-TTZzwV-PT_6gAC1Gp5PgYyHcrA@mail.gmail.com/
> > > > > ).
> > > >
> > > > And my point is that on ARM64 the ACPI subsystem does not need to
> > > > access IO ports.
> > > >
> > > > It may not even need to access them on x86, but that depends on the
> > > > platform firmware in use.
> >
> > Well at least it does compile code calling outb() in
> > drivers/acpi/ec.c:acpi_ec_write_cmd().
>
> That's the EC driver which is not used on arm64 AFAICS and that driver
> itself can be made depend on HAS_IOPORT.
Ah ok good to know.
Looking further there is also an inb_p() in
drivers/acpi/processor_idle.c:acpi_idle_bm_check(). That does look x86
specific though. There are a few more in the same file in
acpi_idle_do_entry() and acpi_idle_play_dead() they both look like
alternative mechanisms though interestingly one of the sites checks for
ACPI_CSTATE_SYSTEMIO while the other doesn't. Also it seems to me that
processor_idle.c is compiled when ACPI_PROCESSOR_IDLE is set which is
selected by ACPI_PROCESSOR which gets set for ARM64 as well.
Then there is a few more calls in drivers/acpi/osl.c which currently
gets compiled on all architectures as well.
I think we could ifdef all of these as it seems there are always
alternative paths. But I'm not sure if that makes sense if ACPI only
works on platforms with HAS_IOPORT anyway. From a cursory look it seems
even the not yet merged LoongArch would set HAS_IOPORT.
What do you think?
>
> > Not sure if there is an
> > alternative path at runtime if there is then we might want to instead
> > use ifdefs to always use the non I/O port path if HAS_IOPORT is
> > undefined.
> >
> > > > If arm64 is going to set HAS_IOPORT, then fine, but is it (and this
> > > > applies to ia64 too)?
> >
> > Yes x86, arm64 and ia64 that is all arches that set ACH_SUPPORTS_ACPI
> > all select HAS_IOPORT too. See patch 02 or the summary in the cover
> > letter which notes that only s390, nds32, um, h8300, nios2, openrisc,
> > hexagon, csky, and xtensa do not select it.
>
> If that is the case, there should be no need to add the extra
> dependency to CONFIG_ACPI.
>
> > > > > > > we depend on HAS_IOPORT unconditionally.
> > > > > > >
> > > > > > > Co-developed-by: Arnd Bergmann <[email protected]>
> > > > > > > Signed-off-by: Arnd Bergmann <[email protected]>
> > > > > > > Signed-off-by: Niklas Schnelle <[email protected]>
> > > > > > > ---
> > > > > > > drivers/acpi/Kconfig | 1 +
> > > > > > > 1 file changed, 1 insertion(+)
> > > > > > >
> > > > > > > diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> > > > > > > index cdbdf68bd98f..b57f15817ede 100644
> > > > > > > --- a/drivers/acpi/Kconfig
> > > > > > > +++ b/drivers/acpi/Kconfig
> > > > > > > @@ -9,6 +9,7 @@ config ARCH_SUPPORTS_ACPI
> > > > > > > menuconfig ACPI
> > > > > > > bool "ACPI (Advanced Configuration and Power Interface) Support"
> > > > > > > depends on ARCH_SUPPORTS_ACPI
> > >
> > > Besides, I'm not sure why ARCH_SUPPORTS_ACPI cannot cover this new dependency.
> >
> > If you prefer to have the dependency there that should work too yes.
>
> I would prefer that.
>
> IMO, if ARCH_SUPPORTS_ACPI is set, all of the requisite dependencies
> should be met.
I personally think it makes sense to have an explicit HAS_IOPORT
dependency even if it's already selected by all architectures setting
ARCH_SUPPORTS_ACPI adding it there as a dependency at the very least
documents its, currently unconditional, compile-time dependency.