Re: [PATCH RESEND] sched: Move some scheduler fields to new static branch API

[Peter Zijlstra <peterz@infradead.org>]

On Wed, Sep 02, 2026 at 08:18:04AM +0000, Hongyan Xia wrote:
> Hi Peter,
> 
> On 8/19/2026 5:28 PM, Peter Zijlstra wrote:
> > On Wed, Aug 19, 2026 at 09:04:03AM +0000, Hongyan Xia wrote:
> >> On 8/19/2026 4:44 PM, Peter Zijlstra wrote:
> >>> On Wed, Aug 19, 2026 at 08:09:38AM +0000, Hongyan Xia wrote:
> >>>> From: Hongyan Xia <hongyan.xia@transsion.com>
> >>>>
> >>>> __cfs_bandwidth_used uses struct static_key directly which is
> >>>> deprecated. Fix.
> >>>>
> >>>> sk_dynamic_* uses static_key_{enable/disable}(), which aren't really
> >>>> deprecated, but take the opportunity to move to the new static_branch_*
> >>>> APIs to be consistent.
> >>>>
> >>>> No functional change.
> >>>>
> >>>> Signed-off-by: Hongyan Xia <hongyan.xia@transsion.com>
> >>>> ---
> >>>
> >>> Your emails are encoded in a Microsoft special quoted-printable that my
> >>> scripts don't like.
> >>
> >> Hmm, this patch was sent through the normal git format-patch and
> >> send-email flow, which looks okay on my end and via lore. Do you have
> >> more details so that I can debug and avoid triggering future unhappiness
> >> in your scripts?
> > 
> > I think I fixed the script. But what the thing did was encode '\n' as
> > =0A=. This is two tokens: "=0A" for the '\n' and then "=$" for a
> > continuation line.
> > 
> > It does this for every line, including the last line. Marking the last
> > line as having a continuation resulted in no output, it would just eat
> > the whole message.
> > 
> > Marking the last line as having a continuation is well, bonkers. But my
> > script should now be able to deal with it.  Still, pretty idiotic
> > behaviour on whoever mangled that.
> 
> While working on the latest sched/core, I noticed two of my patches
> 
> d92d1a182dc2d5dc5e4418765739f56bcbde806a, and
> 087b40fe5934e4b8aa80b29b3debbd6542756ffd
> 
> have both changed my name into
> 
> Author: Hongyan Xia =0A= <hongyan.xia@transsion.com>
> 
> While =0A= is certainly a cute last name, I want to ask if this has 
> anything to do with the Outlook fix you mentioned last time. If not, 
> I'll see what else could have gone wrong.

Argh, sorry about that. Sometimes I fail to spot issues like this. Let
me go rebase those patches and fix.