linux-kernel - Re: [PATCH v8] cpuidle, ACPI: Evaluate LPI arch

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: <20230929160114.eq5omxyauu27two7@bogus>
Date:   Fri, 29 Sep 2023 17:01:14 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Will Deacon <will@...nel.org>
Cc:     Oza Pawandeep <quic_poza@...cinc.com>, catalin.marinas@....com,
        Sudeep Holla <sudeep.holla@....com>, rafael@...nel.org,
        lenb@...nel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH v8] cpuidle, ACPI: Evaluate LPI arch_flags for broadcast
 timer

On Fri, Sep 29, 2023 at 04:04:59PM +0100, Will Deacon wrote:
> On Mon, Sep 18, 2023 at 10:21:40AM -0700, Oza Pawandeep wrote:
> > Arm® Functional Fixed Hardware Specification defines LPI states,
> > which provide an architectural context loss flags field that can
> > be used to describe the context that might be lost when an LPI
> > state is entered.
> > 
> > - Core context Lost
> >         - General purpose registers.
> >         - Floating point and SIMD registers.
> >         - System registers, include the System register based
> >         - generic timer for the core.
> >         - Debug register in the core power domain.
> >         - PMU registers in the core power domain.
> >         - Trace register in the core power domain.
> > - Trace context loss
> > - GICR
> > - GICD
> > 
> > Qualcomm's custom CPUs preserves the architectural state,
> > including keeping the power domain for local timers active.
> > when core is power gated, the local timers are sufficient to
> > wake the core up without needing broadcast timer.
> > 
> > The patch fixes the evaluation of cpuidle arch_flags, and moves only to
> > broadcast timer if core context lost is defined in ACPI LPI.
> > 
> > Fixes: a36a7fecfe607 ("Add support for Low Power Idle(LPI) states")
> > Reviewed-by: Sudeep Holla <sudeep.holla@....com>
> > Acked-by: Rafael J. Wysocki <rafael@...nel.org>
> > Signed-off-by: Oza Pawandeep <quic_poza@...cinc.com>
> > ---
> > 
> > Notes:
> >     Will/Catalin: Rafael has acked and he prefers to take it via arm64 tree
> > 
> > diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
> > index 4d537d56eb84..269d21209723 100644
> > --- a/arch/arm64/include/asm/acpi.h
> > +++ b/arch/arm64/include/asm/acpi.h
> > @@ -9,6 +9,7 @@
> >  #ifndef _ASM_ACPI_H
> >  #define _ASM_ACPI_H
> >  
> > +#include <linux/cpuidle.h>
> >  #include <linux/efi.h>
> >  #include <linux/memblock.h>
> >  #include <linux/psci.h>
> > @@ -44,6 +45,23 @@
> >  
> >  #define ACPI_MADT_GICC_TRBE  (offsetof(struct acpi_madt_generic_interrupt, \
> >  	trbe_interrupt) + sizeof(u16))
> > +/*
> > + * Arm® Functional Fixed Hardware Specification Version 1.2.
> > + * Table 2: Arm Architecture context loss flags
> > + */
> > +#define CPUIDLE_CORE_CTXT		BIT(0) /* Core context Lost */
> > +
> > +static __always_inline void _arch_update_idle_state_flags(u32 arch_flags,
> > +							unsigned int *sflags)
> 
> Why can't this just be 'static inline'?
> 
> > +{
> > +	if (arch_flags & CPUIDLE_CORE_CTXT)
> > +		*sflags |= CPUIDLE_FLAG_TIMER_STOP;
> > +}
> > +#define arch_update_idle_state_flags _arch_update_idle_state_flags
> 
> Usually, the function and the macro have the same name for this pattern,
> so I think it would be more consistent to drop the leading underscore
> from the C function name.
>

Sorry that's me telling him looking at some other example I think. I don't
have a strong opinion, just referred examples doing this way I guess.

Oza, please check it to as it was before I requested this.

--
Regards,
Sudeep