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

[Dmitry Baryshkov]

On 03/04/2025 12:35, Srinivas Kandagatla wrote:
> On 03/04/2025 10:31, Dmitry Baryshkov wrote:
> > On Thu, 3 Apr 2025 at 12:27, Srinivas Kandagatla
> > <srinivas.kandagatla@xxxxxxxxxx> 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@xxxxxxxxxx wrote:
> > > > > > > > > From: Srinivas Kandagatla <srinivas.kandagatla@xxxxxxxxxx>
> > > > > > > > >
> > > > > > > > > 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@xxxxxxxxxx/T/ 
> #r01449e17cf6f9396967a822a0460ad4b1245e914

LGTM, thanks. Then I don't understand what is causing the controversy 
from Greg's side. The only piece of information that got lost is that 
Mark has found an issue with the previous version of the patch (I'd have 
added that information between the tags as you've squashed the patches).

> 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


--
With best wishes
Dmitry