NAK: [SRU][H, I][PATCH 0/2] cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and offline

[Philip Cox]

I have spoken to Tim, and I have got a cherry-pick to work cleanly for both
hirsute and impish where the format-patch/am didn't.  I am working on
sending out a v2 of this change.

On Tue, Nov 16, 2021 at 9:35 AM Kleber Souza <kleber.souza at canonical.com>
wrote:

> Hey Tim,
>
> On 16.11.21 13:38, Tim Gardner wrote:
> > Commit dbea75fe18f60e364de6d994fc938a24ba249d81 is a clean cherry-pick
> > to both repos. We only use 'backported' when there is a conflict. As
>
> It was me who instructed Phil to send them as "backported from ..." and
> in two patches because the same version cannot be applied to both trees.
>
> These patches are not a clean cherry-picks in the meaning that we use it,
> which is somewhat different from upstream.
>
> Our general rule is that if you can create a patch from that original sha1
> with "git format-patch" and apply it with "git am" on the destination
> tree that would be considered a "cherry picked from ...". Otherwise,
> if you need to make any changes, including context adjustments, it's
> considered a "backported from ...".
>
>
> Kleber
>
> > Stefan mentioned, always provide a brief description of the conflict
> > resolution after your S-O-B. Otherwise 'git cherry-pick -s -x' leaves
> > the right info in the patch, though you still have to add the BugLink.
> > See kteam-tools/maintscripts/maint-modify-patch for that.
> >
> > When sending version 2 be sure to note that in the subject, e.g., "
> > [SRU][H, I][PATCH 0/2 v2] cpufreq: intel_pstate: Clear HWP desired on
> > suspend/shutdown and offline".
> >
> > As with an upstream patch, note in the patch description what the
> > changes were from v1-->v2.
> >
> > rtg
> >
> > On 11/15/21 11:43 AM, Philip Cox wrote:
> >> From: "Rafael J. Wysocki" <rafael.j.wysocki at intel.com>
> >>
> >> BugLink: https://bugs.launchpad.net/bugs/1950584
> >>
> >> [Impact]
> >>
> >> "Commit a365ab6b9dfb ("cpufreq: intel_pstate: Implement the
> >>    ->adjust_perf() callback") caused intel_pstate to use nonzero HWP
> >>    desired values in certain usage scenarios, but it did not prevent
> >>    them from being leaked into the confugirations in which HWP desired
> >>    is expected to be 0"
> >>
> >> I believe I'm seeing this issue on my laptop during suspend/resume. The
> upstream fix is:
> >>
> >> commit dbea75fe18f60e364de6d994fc938a24ba249d81
> >> Author: Rafael J. Wysocki <rafael.j.wysocki at intel.com>
> >> Date: Wed Nov 3 19:43:47 2021 +0100
> >>
> >>       cpufreq: intel_pstate: Clear HWP desired on suspend/shutdown and
> offline
> >>
> >> [Fix]
> >>
> >> dbea75fe18f60e364de6d994fc938a24ba249d81 cpufreq: intel_pstate: Clear
> HWP desired on suspend/shutdown and offline
> >>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20211116/fe428467/attachment.html>