linux-kernel - Re: (subset) [PATCH v3 0/9] spi: cadence-qspi: add Mobileye EyeQ5 support

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240424-calm-wolverine-of-drama-0349dc@lemur>
Date: Wed, 24 Apr 2024 15:53:03 -0400
From: Konstantin Ryabitsev <konstantin@...uxfoundation.org>
To: Mark Brown <broonie@...nel.org>
Cc: Conor Dooley <conor@...nel.org>, 
	Théo Lebrun <theo.lebrun@...tlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, 
	Rob Herring <robh+dt@...nel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, 
	Conor Dooley <conor+dt@...nel.org>, Vaishnav Achath <vaishnav.a@...com>, 
	Thomas Bogendoerfer <tsbogend@...ha.franken.de>, Rob Herring <robh@...nel.org>, linux-spi@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-mips@...r.kernel.org, 
	Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>, Gregory CLEMENT <gregory.clement@...tlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: (subset) [PATCH v3 0/9] spi: cadence-qspi: add Mobileye EyeQ5
 support

On Wed, Apr 24, 2024 at 10:01:56AM +0900, Mark Brown wrote:
> > > Thanks for the pointer. I've created an issue over at b4 to see what
> > > people think about this matter. Current behavior is not intuitive as a
> > > young contributor.
> 
> > FWIW, given I see `having a more confident comment such as
> > "(commit not applied)".` there, having (no commit info) doesn't mean
> > that it wasn't applied always. Sometimes I've found that due to changes
> > in the patch b4 could not detect that it was applied and reported (no
> > commit info).
> 
> Right, it can't prove a negative - if it can't find the patch it could
> be because it wasn't sent against current code and got changed
> sufficiently in application to cause issues.

We can also be a bit more relaxed. For example, we can look at 
consecutive commits and compare the subjects to see if there's a match.  
I'll see if that's something I can add in.

In general, though, I prefer to push people in a different direction -- 
we really shouldn't be fixing up people's patches, because this 
misattributes the code to the wrong author. Instead, we really should 
either ask senders to send an updated revision, or make the changes in 
merge commits instead.

Merge commits can be created using "b4 shazam -M", but I must admit that 
editing the contents of the merge commit isn't really that 
straightforward, unfortunately.

-K