Re: [PATCH 0/8] nvmem: Let layout drivers be modules

[Miquel Raynal <miquel.raynal@bootlin.com>]

Hi Rafał,

rafal@milecki.pl wrote on Mon, 06 Mar 2023 15:23:50 +0100:

> On 2023-03-06 15:18, Miquel Raynal wrote:
> > Hi Rafał,
> > 
> > rafal@milecki.pl wrote on Mon, 06 Mar 2023 14:57:03 +0100:
> >   
> >> On 2023-03-06 14:35, Miquel Raynal wrote:  
> >> > Hi Michael,
> >> >
> >> > michael@walle.cc wrote on Mon, 06 Mar 2023 14:01:34 +0100:
> >> >  
> >> >> > Miquel Raynal (8):
> >> >> >   of: Fix modalias string generation
> >> >> >   of: Change of_device_get_modalias() main argument
> >> >> >   of: Create an of_device_request_module() receiving an OF node
> >> >> >   nvmem: core: Fix error path ordering
> >> >> >   nvmem: core: Handle the absence of expected layouts
> >> >> >   nvmem: core: Request layout modules loading
> >> >> >   nvmem: layouts: sl28vpd: Convert layout driver into a module
> >> >> >   nvmem: layouts: onie-tlv: Convert layout driver into a module  
> >> >> >> With the fixes series [1] applied:  
> >> >
> >> > Thanks for the series! Looks good to me. I believe both series can live
> >> > in separate tress, any reason why we would like to avoid this? I am > keen
> >> > to apply [1] into the mtd tree rather soon.  
> >> >> Given past events with nvmem patches I'm against that.
> >> >> Let's wait for Srinivas to collect pending patches, let them spend a  
> >> moment in linux-next maybe, ask Srinivas to send them to Greg early if
> >> he can. That way maybe you can merge Greg's branch (assuming he >> doesn't
> >> rebase).  
> > 
> > Just to be on the same page, we're talking about the mtd core fixups to
> > handle correctly probe deferrals in the nvmem side.
> > 
> > Applying mtd patches then nvmem patches is totally fine in this order.
> > Applying nvmem patches and then mtd patches creates a range of commits
> > where some otp devices might have troubles probing if:
> > - a layout driver is used
> > - the driver is compiled as a module
> > - the driver is also not installed in an initramfs
> > 
> > I was actually asking out loud whether we should care about this
> > commit range given the unlikelihood that someone would have troubles
> > with this while bisecting a linux-next kernel.
> > 
> > So getting an immutable tag from Greg would not help. The opposite
> > might make sense though, and involves that I apply [1] to mtd/next
> > rather soon anyway, I guess?  
> 
> The problem IIUC is nvmem.git / for-next containing broken code after
> adding nvmem stuff. That is unless Srinivas takes your patches in some
> way. Hopefully not by waiting for 6.4-rc1.

I don't follow. There will be nothing broken after applying the nvmem
patches, at least nothing more than today. I will apply the patches
provided by Michael, they fix existing issues, nothing related to the
nvmem changes. Just, it is easier to trigger these issues with the
nvmem series thanks to the probe deferral situations.

Both series can live on their own. If required I will produce an
immutable tag to Greg.

Thanks,
Miquèl