From: Maxime Ripard <email@example.com> To: Samuel Holland <firstname.lastname@example.org> Cc: Alessandro Zummo <email@example.com>, Alexandre Belloni <firstname.lastname@example.org>, Chen-Yu Tsai <email@example.com>, Jernej Skrabec <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org Subject: Re: [PATCH] rtc: sun6i: Add NVMEM provider Date: Tue, 25 May 2021 10:24:16 +0200 [thread overview] Message-ID: <20210525082416.jkqmlkbdx6nhrens@gilmour> (raw) In-Reply-To: <email@example.com> [-- Attachment #1: Type: text/plain, Size: 1972 bytes --] On Sun, May 09, 2021 at 10:39:30PM -0500, Samuel Holland wrote: > On 4/30/21 4:02 AM, 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 <firstname.lastname@example.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 want the user to be able to pass information to the bootloader (to > select a boot device, e.g. reboot to FEL). I also want the user to be > able to read data stored to these registers by system firmware (e.g. > crust writes exception information there). It's not really related to > standby. What information do you want to provide? This looks like punching through the abstraction layer provided by the kernel. This is also an issue since it ties an ABI to the use of crust: if there's another user for those RTC registers at some point, the userspace would have no way to tell whether or not crust is being used and might get complete garbage (compared to what crust usually provides) instead. > I would want to stack a nvmem-reboot-mode on top to give friendlier > names to some of the numbers, but I don't see a problem with root having > direct access to the registers. It's no different from /dev/nvram > providing access to the PC CMOS RAM. And those solutions have issues too. efivarfs for example can totally brick the system it runs on if the user has an unfortunate rm -rf. Maxime [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2021-05-25 8:24 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-19 1:45 Samuel Holland 2021-04-30 9:02 ` Maxime Ripard 2021-05-04 15:33 ` Alexandre Belloni 2021-05-10 3:39 ` Samuel Holland 2021-05-10 8:00 ` Alexandre Belloni 2021-05-25 8:24 ` Maxime Ripard [this message] 2021-05-27 4:09 ` Samuel Holland 2022-04-13 23:17 Samuel Holland 2022-04-15 18:26 ` Jernej Škrabec 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=20210525082416.jkqmlkbdx6nhrens@gilmour \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH] rtc: sun6i: Add NVMEM provider' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).