Hi Rafał, rafal@xxxxxxxxxx wrote on Mon, 06 Mar 2023 14:57:03 +0100: > On 2023-03-06 14:35, Miquel Raynal wrote: > > Hi Michael, > > > > michael@xxxxxxxx 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
