[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180207184643.GA3404@piout.net>
Date: Wed, 7 Feb 2018 19:46:43 +0100
From: Alexandre Belloni <alexandre.belloni@...tlin.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>
Subject: Re: [PATCH] char: nvram: disable on ARM
On 07/02/2018 at 16:47:00 +0100, Alexandre Belloni wrote:
> > >> > I really don't think anyone is using that but I don't really know much
> > >> > about x86 and the specification this may be part of.
> > >> >
> > >> > I see the info may be used in drivers/video/fbdev/ and
> > >> > drivers/platform/x86/thinkpad_acpi.c
> > >>
> > >> The thinkpad_acpi driver seems to look at some other bytes
> > >> in the nvram, which have a platform specific meaning.
> > >>
> > >
> > > Yeah, I was more concerned that they need drivers/char/nvram.c for
> > > nvram_read_byte so we can't simply remove the driver.
> >
> > Ok, so the procfs interface may be obsolete, but we still need an
> > interface into the CMOS NVRAM data.
> >
>
> Actually, I just found
> https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to
>
> So it seems to have real values for some people (even if they are
> wrong).
>
> That also points to https://sourceforge.net/projects/nvram-wakeup/ but I
> don't think it is necessary. The RTC driver should be able to wakeup an
> x86 platform.
>
> All the other uses of /dev/nvram I could find with a simple google
> search (i.e. saving and restoring CMOS settings) could just use
> /sys/class/rtc/rtc0/device/nvram
>
Ok, the chromeos guys are using it for verified boot it seems:
https://chromium.googlesource.com/chromiumos/platform/vboot_reference
I'm wondering whether they really care about the checksum though.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
Powered by blists - more mailing lists