linux-kernel - Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15

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] [thread-next>] [day] [month] [year] [list]
Message-ID: <56cbe0a0-048e-45a2-87f2-e2515c7e7414@linaro.org>
Date: Thu, 3 Apr 2025 10:35:15 +0100
From: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Greg KH <gregkh@...uxfoundation.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 00/13] nvmem: patches (set 1) for 6.15



On 03/04/2025 10:31, Dmitry Baryshkov wrote:
> On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
> <srinivas.kandagatla@...aro.org> wrote:
>>
>>
>>
>> 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.
> 
> Then there should be no Fixes tags. Is the series that you are sending
> visible somewhere?

Yes, there is no fixes tags in v2 series,

Here is what is sent to as v2:
https://lore.kernel.org/lkml/47a3a851-f737-4772-87c6-98613347435c@linaro.org/T/#r01449e17cf6f9396967a822a0460ad4b1245e914


thanks,
Srini
> 
>>
>> 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
>>>
>>>
> 
> 
>