Received-SPF: pass (google.com: domain of linux-kernel+bounces-71255-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Mon, 19 Feb 2024 12:53:58 +0100
From: Marco Felsch <m.felsch@pengutronix.de>
To: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Michael Walle <michael@walle.cc>, srinivas.kandagatla@linaro.org,
	gregkh@linuxfoundation.org, rafal@milecki.pl,
	linux-kernel@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [RFC PATCH] nvmem: core: add sysfs cell write support
Message-ID: <20240219115358.xui5fpoisvsubdyb@pengutronix.de>
References: <20240215211401.1201004-1-m.felsch@pengutronix.de>
 <CZ6DFL6061FS.2WMDPMSSBXX8S@walle.cc>
 <20240216100750.zxl4wncbgpulr2cc@pengutronix.de>
 <20240219120414.32395299@xps-13>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240219120414.32395299@xps-13>

On 24-02-19, Miquel Raynal wrote:
> Hi Marco,
> 
> m.felsch@pengutronix.de wrote on Fri, 16 Feb 2024 11:07:50 +0100:
> 
> > Hi Michael,
> > 
> > On 24-02-16, Michael Walle wrote:
> > > Hi,
> > > 
> > > On Thu Feb 15, 2024 at 10:14 PM CET, Marco Felsch wrote:  
> > > > @@ -432,6 +466,7 @@ static int nvmem_populate_sysfs_cells(struct nvmem_device *nvmem)
> > > >  	struct bin_attribute **cells_attrs, *attrs;
> > > >  	struct nvmem_cell_entry *entry;
> > > >  	unsigned int ncells = 0, i = 0;
> > > > +	umode_t mode;
> > > >  	int ret = 0;
> > > >  
> > > >  	mutex_lock(&nvmem_mutex);
> > > > @@ -456,15 +491,18 @@ static int nvmem_populate_sysfs_cells(struct nvmem_device *nvmem)
> > > >  		goto unlock_mutex;
> > > >  	}
> > > >  
> > > > +	mode = nvmem_bin_attr_get_umode(nvmem);
> > > > +
> > > >  	/* Initialize each attribute to take the name and size of the cell */
> > > >  	list_for_each_entry(entry, &nvmem->cells, node) {
> > > >  		sysfs_bin_attr_init(&attrs[i]);
> > > >  		attrs[i].attr.name = devm_kasprintf(&nvmem->dev, GFP_KERNEL,
> > > >  						    "%s@%x", entry->name,
> > > >  						    entry->offset);
> > > > -		attrs[i].attr.mode = 0444;  
> > > 
> > > cells are not writable if there is a read post process hook, see
> > > __nvmem_cell_entry_write().
> > > 
> > > if (entry->read_post_processing)
> > > 	mode &= ~0222;  
> > 
> > good point, thanks for the hint :) I will add this and send a non-rfc
> > version if write-support is something you would like to have.
> 
> I like the idea but, what about mtd devices (and soon maybe UBI
> devices)? This may only work on EEPROM-like devices I guess, where each
> area is fully independent and where no erasure is actually expected.

For MTD I would say that you need to ensure that you need to align the
cells correctly. The cell-write should handle the page erase/write cycle
properly. E.g. an SPI-NOR need to align the cells to erase-page size or
the nvmem-cell-write need to read-copy-update the cells if they are not
erase-paged aligned.

Regarding UBI(FS) I'm not sure if this is required at all since you have
an filesystem. IMHO nvmem-cells are very lowelevel and are not made for
filesystem backed backends.

That beeing said: I have no problem if we provide write support for
EEPROMs only and adapt it later on to cover spi-nor/nand devices as
well.

Regards,
  Marco