On Sun, May 09, 2021 at 10:39:30PM -0500, Samuel Holland wrote:

On 4/30/21 4:02 AM, Maxime Ripard wrote:

quoted

Hi,

On Sun, Apr 18, 2021 at 08:45:49PM -0500, Samuel Holland wrote:

quoted

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 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