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

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]

Date:   Mon, 6 Mar 2023 15:18:29 +0100
From:   Miquel Raynal <miquel.raynal@...tlin.com>
To:     Rafał Miłecki <rafal@...ecki.pl>
Cc:     Michael Walle <michael@...le.cc>,
        Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        linux-kernel@...r.kernel.org,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        devicetree@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        Frank Rowand <frowand.list@...il.com>,
        Robert Marko <robert.marko@...tura.hr>,
        Luka Perkov <luka.perkov@...tura.hr>,
        Thomas Petazzoni <thomas.petazzoni@...tlin.com>
Subject: Re: [PATCH 0/8] nvmem: Let layout drivers be modules

Hi Rafał,

rafal@...ecki.pl wrote on Mon, 06 Mar 2023 14:57:03 +0100:

> On 2023-03-06 14:35, Miquel Raynal wrote:
> > Hi Michael,
> > 
> > michael@...le.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