linux-kernel - Re: [PATCH v4 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add JH7100 SoC compatible

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]

Date: Mon, 29 Jan 2024 13:04:29 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Cristian Ciocaltea <cristian.ciocaltea@...labora.com>
Cc: Andrew Lunn <andrew@...n.ch>, Krzysztof Kozlowski
 <krzysztof.kozlowski@...aro.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Rob
 Herring <robh+dt@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Emil Renner Berthing <kernel@...il.dk>, Samin Guo
 <samin.guo@...rfivetech.com>, Alexandre Torgue
 <alexandre.torgue@...s.st.com>, Jose Abreu <joabreu@...opsys.com>, Maxime
 Coquelin <mcoquelin.stm32@...il.com>, Giuseppe Cavallaro
 <peppe.cavallaro@...com>, Jacob Keller <jacob.e.keller@...el.com>,
 netdev@...r.kernel.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v4 1/2] dt-bindings: net: starfive,jh7110-dwmac: Add
 JH7100 SoC compatible

On Mon, 29 Jan 2024 22:57:11 +0200 Cristian Ciocaltea wrote:
> > First off, have another read of our rules:
> > https://www.kernel.org/doc/html/next/process/maintainer-netdev.html#tl-dr
> > :)  
> 
> Oh, net/net-next suffix is required, will make sure to add it next time!
> 
> The 24h period restriction is still applicable for a RESEND that is
> meant to quickly fix a previous submission issue?

Yes, reposting too quickly often leads to reviewers looking at 
the wrong version.

> > IMHO forwarding the review tag to a newer version of the set yourself
> > (like I just did) is fine. None of the tooling I know checks if that
> > the person posting the tag matches the From:  
> 
> Hmm, I didn't actually test, but according to the link Andrew posted
> above, for b4 it might be necessary to make use of the
> `--sloppy-trailers` flag:
> 
> "Accept trailers where the email address of the sender differs from the
> email address found in the trailer itself."

Hah, interesting. Using a corporate address for the tag but ML-friendly
account for sending the email is quite common. I'm surprised. In any
case, our tools don't do this. I think it's kinda pointless unless the
tool can also prove provenance of the tags already in the patch...