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] [day] [month] [year] [list]
Message-ID: <CH0PR02MB8073E0B92F0755D586779788F6C4A@CH0PR02MB8073.namprd02.prod.outlook.com>
Date:   Tue, 3 Oct 2023 14:35:39 +0000
From:   "Pawandeep Oza (QUIC)" <quic_poza@...cinc.com>
To:     'Sudeep Holla' <sudeep.holla@....com>,
        "Pawandeep Oza (QUIC)" <quic_poza@...cinc.com>
CC:     'Will Deacon' <will@...nel.org>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>
Subject: RE: [PATCH v8] cpuidle, ACPI: Evaluate LPI arch_flags for broadcast
 timer



-----Original Message-----
From: Sudeep Holla <sudeep.holla@....com> 
Sent: Tuesday, October 3, 2023 2:46 AM
To: Pawandeep Oza (QUIC) <quic_poza@...cinc.com>
Cc: 'Will Deacon' <will@...nel.org>; Sudeep Holla <sudeep.holla@....com>; catalin.marinas@....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 Mon, Oct 02, 2023 at 07:22:57PM +0000, Pawandeep Oza (QUIC) wrote:
>
>
> -----Original Message-----
> From: Will Deacon <will@...nel.org>
> Sent: Friday, September 29, 2023 8:05 AM
> To: Pawandeep Oza (QUIC) <quic_poza@...cinc.com>
> Cc: sudeep.holla@....com; catalin.marinas@....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 Mon, Sep 18, 2023 at 10:21:40AM -0700, Oza Pawandeep wrote:
> > Arm(r) 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>
> > ---
> > diff --git a/drivers/acpi/processor_idle.c 
> > b/drivers/acpi/processor_idle.c index dc615ef6550a..5c1d13eecdd1
> > 100644
> > --- a/drivers/acpi/processor_idle.c
> > +++ b/drivers/acpi/processor_idle.c
> > @@ -1217,8 +1217,7 @@ static int acpi_processor_setup_lpi_states(struct acpi_processor *pr)
> >  		strscpy(state->desc, lpi->desc, CPUIDLE_DESC_LEN);
> >  		state->exit_latency = lpi->wake_latency;
> >  		state->target_residency = lpi->min_residency;
> > -		if (lpi->arch_flags)
> > -			state->flags |= CPUIDLE_FLAG_TIMER_STOP;
> > +		arch_update_idle_state_flags(lpi->arch_flags, &state->flags);
>
> Hmm, I know Rafael has Acked this, but I think this is pretending to 
> be more generic than it really is. While passing in a pointer to the 
> flags field allows the arch code to set and clear arbitrary flags, 
> we're calling this before we've set CPUIDLE_FLAG_RCU_IDLE, so that cannot be changed.
>
> Why not just name it like it is and return the arch flags directly:
>
> 	state->flags |= arch_get_idle_state_flags(lpi->arch_flags);
>
> Oza:
>
> ?

Not sure if this "?" is by mistake or you didn't follow Will's comment.

The point made was that it is cleaner for arch code to just provide the flags that needs to be set via some helper like 'arch_get_idle_state_flags()'
rather than set/update itself via 'arch_update_idle_state_flags()' like you have in this patch.

I completely agree with Will as this is much cleaner and arch code just returns the requested flags and the core code is still in charge to update the flags.

Oza: oh ! sorry about that, it was some mix-up with the reply to another comment from will where I wanted to point out kernel test robot results. So not sure what happened there.
This comment is already taken care in the patch now. Changed to 'arch_get_idle_state_flags'

--
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ