Received-SPF: pass (google.com: domain of linux-kernel+bounces-157630-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Wed, 24 Apr 2024 15:53:03 -0400
From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Mark Brown <broonie@kernel.org>
Cc: Conor Dooley <conor@kernel.org>, 
	=?utf-8?B?VGjDqW8=?= Lebrun <theo.lebrun@bootlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, 
	Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, 
	Conor Dooley <conor+dt@kernel.org>, Vaishnav Achath <vaishnav.a@ti.com>, 
	Thomas Bogendoerfer <tsbogend@alpha.franken.de>, Rob Herring <robh@kernel.org>, linux-spi@vger.kernel.org, 
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org, 
	Vladimir Kondratiev <vladimir.kondratiev@mobileye.com>, Gregory CLEMENT <gregory.clement@bootlin.com>, 
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Tawfik Bayouk <tawfik.bayouk@mobileye.com>
Subject: Re: (subset) [PATCH v3 0/9] spi: cadence-qspi: add Mobileye EyeQ5
 support
Message-ID: <20240424-calm-wolverine-of-drama-0349dc@lemur>
References: <20240410-cdns-qspi-mbly-v3-0-7b7053449cf7@bootlin.com>
 <171283699002.32012.7629247540689477794.b4-ty@kernel.org>
 <D0QT350IJHFH.36EXE1UT9QM10@bootlin.com>
 <ZidAefc0Ejrklopf@finisterre.sirena.org.uk>
 <D0RF1AKWAEAE.44N64GHMV2ZY@bootlin.com>
 <3f891794-0083-4245-bad7-518b1c48bb7c@linaro.org>
 <D0RIXN4JG6ZA.4W4HN68M9U6I@bootlin.com>
 <20240423-epidemic-schedule-6fa9869b3e87@spud>
 <ZihaBGwVRpI9hV0B@finisterre.sirena.org.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <ZihaBGwVRpI9hV0B@finisterre.sirena.org.uk>

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