public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Marco Felsch <m.felsch@pengutronix.de>
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
Date: Mon, 19 Feb 2024 12:04:14 +0100	[thread overview]
Message-ID: <20240219120414.32395299@xps-13> (raw)
In-Reply-To: <20240216100750.zxl4wncbgpulr2cc@pengutronix.de>

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.

Thanks,
Miquèl

  reply	other threads:[~2024-02-19 11:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-15 21:14 [RFC PATCH] nvmem: core: add sysfs cell write support Marco Felsch
2024-02-16  8:47 ` Michael Walle
2024-02-16 10:07   ` Marco Felsch
2024-02-19 11:04     ` Miquel Raynal [this message]
2024-02-19 11:53       ` Marco Felsch
2024-02-19 13:26         ` Michael Walle
2024-02-20  9:18           ` Miquel Raynal
2024-02-20  9:50             ` Marco Felsch
2024-02-20 10:07               ` Miquel Raynal
2024-02-20 10:16               ` Michael Walle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240219120414.32395299@xps-13 \
    --to=miquel.raynal@bootlin.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=m.felsch@pengutronix.de \
    --cc=michael@walle.cc \
    --cc=rafal@milecki.pl \
    --cc=srinivas.kandagatla@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox