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

  Hello,

Following Greg's opposition to merge the current nvmem layout support
proposal [1], arguing that it would eventually grow the size of the
Linux kernel and asking for some "modularization" support, here is a
proposal to turn layout drivers into regular tristate drivers.

The first three patches are preparation changes in order to extend (and
fix) a little bit the of/device.c support. The fix does not seem to
impact most of the current users so I guess it can live with the rest of
the series in order to avoid future merge conflicts.

The nvmem core is then extended to support the absence of layouts and
possibly lead to probe deferrals when relevant.

Finally, the two existing layout drivers are converted into modules and
their Kconfig symbols changed to tristate.

The base series on which these changes apply is still contained in [1],
I would prefer to keep it as it was and apply this series on top of it.

Tests have been conducted on a Marvell Prestera switch with the mvpp2
Ethernet driver calling for a MAC address stored in the ONIE TLV table
available through a layout driver in an EEPROM/MTD device.

[1] https://github.com/miquelraynal/linux/tree/nvmem-next/layouts

Thanks,
Miquèl

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

 drivers/nvmem/core.c             | 20 ++++++++++++--
 drivers/nvmem/layouts/Kconfig    |  4 +--
 drivers/nvmem/layouts/onie-tlv.c | 15 ++++++++++-
 drivers/nvmem/layouts/sl28vpd.c  | 14 +++++++++-
 drivers/of/device.c              | 45 ++++++++++++++++++++++----------
 include/linux/of_device.h        |  6 +++++
 6 files changed, 84 insertions(+), 20 deletions(-)
  

On Wed, Mar 01, 2023 at 04:22:31PM +0100, Miquel Raynal wrote:
> Hello,
> 
> Following Greg's opposition to merge the current nvmem layout support
> proposal [1], arguing that it would eventually grow the size of the
> Linux kernel and asking for some "modularization" support, here is a
> proposal to turn layout drivers into regular tristate drivers.
> 
> The first three patches are preparation changes in order to extend (and
> fix) a little bit the of/device.c support. The fix does not seem to
> impact most of the current users so I guess it can live with the rest of
> the series in order to avoid future merge conflicts.
> 
> The nvmem core is then extended to support the absence of layouts and
> possibly lead to probe deferrals when relevant.
> 
> Finally, the two existing layout drivers are converted into modules and
> their Kconfig symbols changed to tristate.
> 
> The base series on which these changes apply is still contained in [1],
> I would prefer to keep it as it was and apply this series on top of it.
> 
> Tests have been conducted on a Marvell Prestera switch with the mvpp2
> Ethernet driver calling for a MAC address stored in the ONIE TLV table
> available through a layout driver in an EEPROM/MTD device.
> 
> [1] https://github.com/miquelraynal/linux/tree/nvmem-next/layouts

These look sane to me, thanks for making the changes.

greg k-h
  

> 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:

Tested-by: Michael Walle <michael@walle.cc>

I didn't test module autoloading, but I presume you did.

Thanks for working on this!
-michael

[1] https://lore.kernel.org/r/20230306125805.678668-1-michael@walle.cc/
  

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.

I will handle the remaining deferral errors in the regular mtd path as
discussed on IRC.

> Tested-by: Michael Walle <michael@walle.cc>
> 
> I didn't test module autoloading, but I presume you did.

Yes, I generated an initramfs with Buildroot, in which an overlay
containing the result of modules_install got merged (storage device =y
and nvmem layout to =m). I could observe the modprobe call being
successful and the layout driver being loaded early.

> Thanks for working on this!

👍

> -michael
> 
> [1] https://lore.kernel.org/r/20230306125805.678668-1-michael@walle.cc/

Thanks,
Miquèl
  

Hi Miquel,

Am 2023-03-06 14:35, schrieb Miquel Raynal:
> 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.

I'm fine with that.

-michael

[1] https://lore.kernel.org/r/20230306125805.678668-1-michael@walle.cc/
  

On 2023-03-01 16:22, Miquel Raynal wrote:
> The base series on which these changes apply is still contained in [1],
> I would prefer to keep it as it was and apply this series on top of it.
> 
> (...)
> 
> [1] https://github.com/miquelraynal/linux/tree/nvmem-next/layouts

My experience with kernel development over all subsystems I touched is
that patches should be improved until being clean & acceptable. I never
sent a series with more recent patches fixing issues in earlier patches
of the same seriee.

So my preference would be to get a new, clean & complete set of patches.
  

On Mon, Mar 06, 2023 at 02:54:10PM +0100, Rafał Miłecki wrote:
> On 2023-03-01 16:22, Miquel Raynal wrote:
> > The base series on which these changes apply is still contained in [1],
> > I would prefer to keep it as it was and apply this series on top of it.
> > 
> > (...)
> > 
> > [1] https://github.com/miquelraynal/linux/tree/nvmem-next/layouts
> 
> My experience with kernel development over all subsystems I touched is
> that patches should be improved until being clean & acceptable. I never
> sent a series with more recent patches fixing issues in earlier patches
> of the same seriee.
> 
> So my preference would be to get a new, clean & complete set of patches.

I agree, don't break something and then fix it up in a later patch, that
makes bisection impossible.

thanks,

greg k-h
  

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).
  

Am 2023-03-06 14:57, schrieb Rafał Miłecki:
> 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).

Mh? None of these fixes have anything to do with nvmem (except maybe 
patch
4/4). The bugs were just discovered while I was testing this series. But
OTOH they are kind of a prerequisite for this series. So what are you
suggesting here?

-michael
  

On 2023-03-06 15:03, Michael Walle wrote:
> Am 2023-03-06 14:57, schrieb Rafał Miłecki:
>> 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).
> 
> Mh? None of these fixes have anything to do with nvmem (except maybe 
> patch
> 4/4). The bugs were just discovered while I was testing this series. 
> But
> OTOH they are kind of a prerequisite for this series. So what are you
> suggesting here?

I'm sorry, I didn't realize you are commenting on linked mtd series.
I thought you want to take nvmem patches series over mtd tree ;) My
bad.
  

Am 2023-03-06 15:06, schrieb Rafał Miłecki:
> On 2023-03-06 15:03, Michael Walle wrote:
>> Am 2023-03-06 14:57, schrieb Rafał Miłecki:
>>> 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).
>> 
>> Mh? None of these fixes have anything to do with nvmem (except maybe 
>> patch
>> 4/4). The bugs were just discovered while I was testing this series. 
>> But
>> OTOH they are kind of a prerequisite for this series. So what are you
>> suggesting here?
> 
> I'm sorry, I didn't realize you are commenting on linked mtd series.
> I thought you want to take nvmem patches series over mtd tree ;) My
> bad.

So was Miquel I think ;). But maybe it will make sense to provide a 
stable
tag/branch to srinivas so if someone is using the nvmem-next branch it 
will
work. Although I doubt there are many users of the spi-nor otp stuff.

-michael
  

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?

Thanks,
Miquèl
  

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.
  

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
  

On 2023-03-06 15:29, Miquel Raynal wrote:
> 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.

OK, it's me how didn't follow then.

I thought your mtd fixes are needed before applying nvmem stuff.

It sounds OK then.
  

Hi Rafał,

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

> On 2023-03-06 15:29, Miquel Raynal wrote:
> > 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.  
> 
> OK, it's me how didn't follow then.
> 
> I thought your mtd fixes are needed before applying nvmem stuff.

Yes, that would be ideal. I will produce an immutable branch.

Thanks,
Miquèl
  

Hello,

gregkh@linuxfoundation.org wrote on Mon, 6 Mar 2023 14:55:44 +0100:

> On Mon, Mar 06, 2023 at 02:54:10PM +0100, Rafał Miłecki wrote:
> > On 2023-03-01 16:22, Miquel Raynal wrote:  
> > > The base series on which these changes apply is still contained in [1],
> > > I would prefer to keep it as it was and apply this series on top of it.
> > > 
> > > (...)
> > > 
> > > [1] https://github.com/miquelraynal/linux/tree/nvmem-next/layouts  
> > 
> > My experience with kernel development over all subsystems I touched is
> > that patches should be improved until being clean & acceptable. I never
> > sent a series with more recent patches fixing issues in earlier patches
> > of the same seriee.
> > 
> > So my preference would be to get a new, clean & complete set of patches.  
> 
> I agree, don't break something and then fix it up in a later patch, that
> makes bisection impossible.

Apart from two rather small fixes which I can squash if that's what you
are requesting, most of the series is already fine on its own, fully
working and bisectable. On top of that initial series from Michael I am
adding support for compiling additional code as modules, which is
arguably another feature. I don't see the point in merging them both
besides mixing two different works. Looking at the code shows that every
step is pretty clean, there is nothing going back and forth.

I will anyway try to make it look like a single series with the changes
requested by Rob in v2.

Thanks,
Miquèl