diff mbox series

[RFC,03/32] ACPI: Kconfig: add HAS_IOPORT dependencies

Message ID 20211227164317.4146918-4-schnelle@linux.ibm.com (mailing list archive)
State Handled Elsewhere
Delegated to: Bjorn Helgaas
Headers show
Series Kconfig: Introduce HAS_IOPORT and LEGACY_PCI options | expand

Commit Message

Niklas Schnelle Dec. 27, 2021, 4:42 p.m. UTC
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 <arnd@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@kernel.org>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
---
 drivers/acpi/Kconfig | 1 +
 1 file changed, 1 insertion(+)

Comments

Rafael J. Wysocki Dec. 27, 2021, 4:47 p.m. UTC | #1
On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> ---
>  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
>
Niklas Schnelle Dec. 27, 2021, 5:02 p.m. UTC | #2
On Mon, 2021-12-27 at 17:47 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 5:44 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > ---
> >  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
> >
Rafael J. Wysocki Dec. 27, 2021, 5:12 p.m. UTC | #3
On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > ---
> > >  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
> > >
>
Rafael J. Wysocki Dec. 27, 2021, 5:15 p.m. UTC | #4
On Mon, Dec 27, 2021 at 6:12 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > > ---
> > > >  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
> > > >
> >
Niklas Schnelle Dec. 27, 2021, 5:43 p.m. UTC | #5
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 <rafael@kernel.org> wrote:
> > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > > > ---
> > > > >  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
> > > > >
Rafael J. Wysocki Dec. 28, 2021, 3:20 p.m. UTC | #6
On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <rafael@kernel.org> wrote:
> > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > > > > ---
> > > > > >  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.
Niklas Schnelle Dec. 28, 2021, 4:31 p.m. UTC | #7
On Tue, 2021-12-28 at 16:20 +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 27, 2021 at 6:43 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <rafael@kernel.org> wrote:
> > > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@linux.ibm.com> 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 <schnelle@linux.ibm.com> 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 <arnd@kernel.org>
> > > > > > > Signed-off-by: Arnd Bergmann <arnd@kernel.org>
> > > > > > > Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
> > > > > > > ---
> > > > > > >  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.
diff mbox series

Patch

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