All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Samuel Holland <samuel@sholland.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider
Date: Tue, 4 May 2021 17:33:59 +0200	[thread overview]
Message-ID: <YJFpZzm07ZX3aYsK@piout.net> (raw)
In-Reply-To: <20210430090206.lybmygrt636nysoc@gilmour>

On 30/04/2021 11:02:06+0200, Maxime Ripard wrote:
> Hi,
> 
> On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote:
> > The sun6i RTC provides 32 bytes of general-purpose data registers.
> > They can be used to save data in the always-on RTC power domain.
> > The registers are writable via 32-bit MMIO accesses only.
> > 
> > Expose the region as a NVMEM provider so it can be used by userspace and
> > other drivers.
> > 
> > Signed-off-by: Samuel Holland <samuel@sholland.org>
> 
> As far as I understood, you want to use those registers to implement
> super-standby? If so, while it makes sense for the kernel to be able to
> be able to write to those registers, I guess it would be a bit unwise to
> allow the userspace to access it?

I would think nvmem is still the proper subsystem. I guess maybe we
should have a version of __nvmem_device_get that would ensure exclusive
access to a cell, thus preventing userspace accessing it as long a the
kernel is using it.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

WARNING: multiple messages have this Message-ID (diff)
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Maxime Ripard <maxime@cerno.tech>
Cc: Samuel Holland <samuel@sholland.org>,
	Alessandro Zummo <a.zummo@towertech.it>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@siol.net>,
	linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-sunxi@lists.linux.dev, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider
Date: Tue, 4 May 2021 17:33:59 +0200	[thread overview]
Message-ID: <YJFpZzm07ZX3aYsK@piout.net> (raw)
In-Reply-To: <20210430090206.lybmygrt636nysoc@gilmour>

On 30/04/2021 11:02:06+0200, Maxime Ripard wrote:
> Hi,
> 
> On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote:
> > The sun6i RTC provides 32 bytes of general-purpose data registers.
> > They can be used to save data in the always-on RTC power domain.
> > The registers are writable via 32-bit MMIO accesses only.
> > 
> > Expose the region as a NVMEM provider so it can be used by userspace and
> > other drivers.
> > 
> > Signed-off-by: Samuel Holland <samuel@sholland.org>
> 
> As far as I understood, you want to use those registers to implement
> super-standby? If so, while it makes sense for the kernel to be able to
> be able to write to those registers, I guess it would be a bit unwise to
> allow the userspace to access it?

I would think nvmem is still the proper subsystem. I guess maybe we
should have a version of __nvmem_device_get that would ensure exclusive
access to a cell, thus preventing userspace accessing it as long a the
kernel is using it.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-04 15:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19  1:45 [PATCH] rtc: sun6i: Add NVMEM provider Samuel Holland
2021-04-19  1:45 ` Samuel Holland
2021-04-30  9:02 ` Maxime Ripard
2021-04-30  9:02   ` Maxime Ripard
2021-05-04 15:33   ` Alexandre Belloni [this message]
2021-05-04 15:33     ` Alexandre Belloni
2021-05-10  3:39   ` Samuel Holland
2021-05-10  3:39     ` Samuel Holland
2021-05-10  8:00     ` Alexandre Belloni
2021-05-10  8:00       ` Alexandre Belloni
2021-05-25  8:24     ` Maxime Ripard
2021-05-25  8:24       ` Maxime Ripard
2021-05-27  4:09       ` Samuel Holland
2021-05-27  4:09         ` Samuel Holland
2022-04-13 23:17 Samuel Holland
2022-04-13 23:17 ` Samuel Holland
2022-04-15 18:26 ` Jernej Škrabec
2022-04-15 18:26   ` Jernej Škrabec
2022-05-17 20:49 ` alexandre.belloni
2022-05-17 20:49   ` alexandre.belloni

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=YJFpZzm07ZX3aYsK@piout.net \
    --to=alexandre.belloni@bootlin.com \
    --cc=a.zummo@towertech.it \
    --cc=jernej.skrabec@siol.net \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rtc@vger.kernel.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=maxime@cerno.tech \
    --cc=samuel@sholland.org \
    --cc=wens@csie.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.