On Fri, Jun 28, 2024 at 01:23:47PM +0100, Daniel Golle wrote: > So that's what I did consequently. Using the notification interface > the NVMEM driver can live in drivers/nvmem/ and doesn't need to be > using block internals. > > > And not actually having a user for it is a complete no-go. > > > > The user will be the nvmem provider, you can see the code in earlier > versions of the patchset where I had included it: > > https://patchwork.kernel.org/project/linux-block/patch/96554d6b4d9fa72f936c2c476eb0b023cdd60a64.1717031992.git.daniel@xxxxxxxxxxxxxx/ > > Being another subsystem I thought it'd be better to deal with the > block related things first, and once that has been sorted out I will > move on to add the NVMEM driver and make the necessary changes for > using it on eMMC. It is rather hard to review an interface without the users. I still dislike the idea of notifications from bdev discovery / partition scanning into the users of them. We have one such users in the MD legacy autodetect code, but that has largely been considered at bad idea and distros tend to use mdadm based assembly from initramfs instead. Which IMHO feels like the right thing for nvmem as well, just have an nvmem provider that opens a file for a user provided path and use kernel_read on it. This can covered block devices, character devices and even regular files. It will require initramfs support, but that is pretty much used everywhere for storage discovery and setup anyway.
