Message-ID: <283ac88b-c8d4-47c8-9ff7-935770eca566@linaro.org>
Date: Thu, 3 Apr 2025 10:18:49 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org,
 Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Subject: Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15



On 02/04/2025 12:31, Greg KH wrote:
> On Wed, Apr 02, 2025 at 09:19:17AM +0100, Srinivas Kandagatla wrote:
>> HI Greg,
>>
>> On 01/04/2025 20:18, Greg KH wrote:
>>> On Sun, Mar 09, 2025 at 02:56:50PM +0000, srinivas.kandagatla@...aro.org wrote:
>>>> From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
>>>>
>>>> Hi Greg,
>>>>
>>>> Here are few nvmem patches for 6.15, Could you queue
>>>> these for 6.15.
>>>>
>>>> patche include
>>>> 	- updates to bindings to include MSM8960, X1E80100, MS8937,
>>>> 	  IPQ5018
>>>> 	- add support to bit offsets for register strides exceeding
>>>> 	  single byte
>>>> 	- add rockchip-otp variants.
>>>> 	- Few enhancements in qfprom and rochchip nvmem providers.
>>>
>>> Ok, I wanted to apply these, and tried to, but they fail horribly
>>> because:
>>>
>>> Commit: 1b14625bd6d4 ("nvmem: qfprom: switch to 4-byte aligned reads")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>> Commit: a8a7c7e34093 ("nvmem: core: update raw_len if the bit reading is required")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>> Commit: d44f60348d8c ("nvmem: core: fix bit offsets of more than one byte")
>>> 	Fixes tag: Fixes: 11ccaa312111 ("nvmem: core: verify cell's raw_len")
>>> 	Has these problem(s):
>>> 		- Target SHA1 does not exist
>>
>> Looks some of your scripts or b4 is picking up older version v1 of the
>> patchset
>>
>> None of the above patches have Fixes tags in the V2 patches that I shared
>> aswell as patches in linux-next.
> 
> Yes, that looks odd, it looks like b4 pulled in the wrong series, yes.
> 

Even that looked incorrect, as the v1 series only had one patch("[PATCH 
12/14] nvmem: make the misaligned raw_len non-fatal") that had fixes 
tag. Not sure how these 3 patches are tagged as fixes.

> But, that's even worse.  Those "fixes" are now not actually marked as
> fixes of the previous patch.  So that information is totally lost, and

Its because this patch("PATCH 12/14] nvmem: make the misaligned raw_len 
non-fatal") is taken as fixup patch and wrapped into the original patch 
("nvmem: core: verify cell's raw_len"), Also the sha will not be valid 
for linus or char-misc tree.

> again, the first commit here, "nvmem: core: verify cell's raw_len" is
> broken so much that it took 3 other changes to fix it, which implies
> that bisection would cause problems if you hit it in the middle here.
> 

All the patches related to this are enhancements to nvmem core to allow 
specifying bit offsets for nvmem cell that have 4 bytes strides.

Specially this check is also an additional check in core to make sure 
that cell offsets are aligned to register strides.

> While fixing patches is great, and something we do in the tree all the
> time, let's not purposefully break things and then fix them up in the
> same exact patch series please.  That's just sloppy engineering.
> 
> Please redo this series completely.  I can take the "new device support"

I can send them but its going to be exactly same series, I dont think 
anything will change as all of these patches are enhancements and there 
are no fixes.

I hope this clarifies a bit, Please let me know if you still want me to 
resend this series, which is going to be exactly same.

--srini
> patches at any time, and really, those should be marked with Cc: stable
> to get backported, right?  The other ones are written as if they are
> fixes, so again, I can take them any time, no need to wait for the -rc1
> merge cycle.
> 
> thanks,
> 
> greg k-h

Powered by blists - more mailing lists