linux-kernel - Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state in rtl8366rb

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]

Date: Mon, 11 Mar 2024 15:11:33 -0400
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Simon Horman <horms@...nel.org>, 
	Luiz Angelo Daros de Luca <luizluca@...il.com>, Linus Walleij <linus.walleij@...aro.org>, 
	Alvin Šipraga <alsi@...g-olufsen.dk>, Andrew Lunn <andrew@...n.ch>, 
	Florian Fainelli <f.fainelli@...il.com>, Vladimir Oltean <olteanv@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 2/4] net: dsa: realtek: keep default LED state
 in rtl8366rb

On Mon, Mar 11, 2024 at 11:52:28AM -0700, Jakub Kicinski wrote:
> > > Eh, hum. He does according to the X-Mailer header. More importantly
> > > I thought the RFC to PATCH transition resetting version numbering
> > > is how we always operated. Maybe b4 should be fixed?  
> > 
> > There is no way to make it work reliably the way you propose,
> 
> Could you describe what the problem is?
> Cover letter + date seems like fairly strong signal to me.

The problem is tracking the series all the way from its inception to its final
inclusion into the tree. Links to previous versions of the series are
sometimes included in the cover letter, but they are free-form and we can't
reliably parse them.

Specifically, we need to be able to *reliably* retrieve any previous/new
versions of the same series:

- to allow running range-diff between vN-1 and vN
- to allow checking if there is a newer version of the series available
- to allow specifying series dependencies (this series depends on series X
  version Y or newer)

If dropping the RFC prefix resets the version count, then the above breaks
unless we also use a different change-id, and if we do that, then we lose
change history.

> > so I strongly suggest that we do it the way b4 currently works:
> > 
> > - a series can start with RFC in the prefixes to indicate that it's not
> >   something to be considered for inclusion
> > - when the author feels that the series is ready for maintainers'
> >   consideration, they simply drop the RFC and keep the same change-id and
> >   versioning info; e.g. [PATCH RFC v3] -> [PATCH v4]
> 
> It's not a pain point for networking.
> 
> While I have you - it'd be great if the patchwork bot did not
> repeatedly set patches to Superseded. Sometimes we want to keep and
> apply non-latest version, because the latest version was posted based
> on non-expert review, or we changed our mind.

That's a request to helpdesk. :)

> > Resetting the versioning requires resetting the change-id of the series, or a
> > lot of automation breaks.
> 
> What is "change-id of the series"?

It's the line that says "change-id: " at the bottom of the cover letter and
doesn't change between v1..vN of the series. This is how we know it's the same
series and are able to retrieve the entire series history without guesswork.

-K