[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e8c91706-1a94-4e3d-b2a9-9d670021bbc8@linaro.org>
Date: Thu, 3 Apr 2025 10:27:04 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Greg KH <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15
On 03/04/2025 10:25, Dmitry Baryshkov wrote:
> On 03/04/2025 12:18, Srinivas Kandagatla wrote:
>>
>>
>> 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.
>
> I think Greg is asking to squash the fixup into the relevant patch.
Its already squashed up in v2.
thanks,
Srini
>
>>
>> --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