linux-kernel - Re: [RFC 03/32] ACPI: Kconfig: add HAS

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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6405f7f91fffdefe504b238bb0aebf653561fbb.camel@linux.ibm.com>
Date:   Tue, 28 Dec 2021 17:31:25 +0100
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Arnd Bergmann <arnd@...nel.org>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        John Garry <john.garry@...wei.com>,
        Nick Hu <nickhu@...estech.com>,
        Greentime Hu <green.hu@...il.com>,
        Vincent Chen <deanbo422@...il.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>, Guo Ren <guoren@...nel.org>,
        Len Brown <lenb@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Linux PCI <linux-pci@...r.kernel.org>,
        linux-riscv@...ts.infradead.org, linux-csky@...r.kernel.org,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>
Subject: Re: [RFC 03/32] ACPI: Kconfig: add HAS_IOPORT dependencies

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@...ux.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@...nel.org> wrote:
> > > > On Mon, Dec 27, 2021 at 6:02 PM Niklas Schnelle <schnelle@...ux.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@...ux.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@...nel.org>
> > > > > > > Signed-off-by: Arnd Bergmann <arnd@...nel.org>
> > > > > > > Signed-off-by: Niklas Schnelle <schnelle@...ux.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.