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

[Srinivas Kandagatla]

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.

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