Re: [PATCH v8 5/9] block: implement NVMEM provider

[Christoph Hellwig <hch@infradead.org>]

On Fri, Jul 24, 2026 at 11:10:58AM +0200, Loic Poulain wrote:
> Right, I was planning to add partition support in a follow-up series.
> But since this is really supposed to be a block-agnostic feature,
> whether it's a disk or a partition, I'll include partition in v8.

Please include the partitions, as including them or not matters for
the interfaces.  What is holding that support back now?  fwnode
magic?

> > Also once you register the whole devices as nvmem provider, we really
> > should keep it from being used a block device, shouldn't we?
> 
> 
> I'm not sure, the whole concept is block backed NVMEM, so we still
> need to add that block as base layer, though we could discuss
> suppressing uevent for it. Preventing block usage would make the
> feature much more intrusive than other NVMEM providers like MTD, where
> the underlying device stays accessible. And we may genuinely still
> want to write the disk (e.g. for factory provisioning), updating the
> very data the cells point to, etc. There's also the layering aspect,
> if a disk (e.g. mmcblk0) has logical partitions on top (mmcblk0pX), we
> still register/expose the whole disk mmcblk0 as a block device
> regardless. So if a disk contains NVMEM cells, I think it should still
> be exposed as a block device as well.

So we now get two unsynchronized ways to access the same device?
At least we need to prevent exclusive openers on the block device
side.  And document the side channel very well.