Re: [PATCH] char: nvram: disable on ARM
From: Arnd Bergmann <arnd@arndb.de>
Date: 2018-02-07 14:00:04
Also in:
lkml
On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni [off-list ref] wrote:
On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:quoted
On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
quoted
quoted
quoted
$ cat /proc/driver/nvram Checksum status: valid # floppies : 0 Floppy 0 type : none Floppy 1 type : none HD 0 type : none HD 1 type : none HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0 HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0 DOS base memory: 635 kB Extended memory: 65535 kB (configured), 65535 kB (tested) Gfx adapter : EGA, VGA, ... (with BIOS) FPU : not installedI 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.cThe 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.
I see that the x86 version of nvram_read_byte is just a wrapper
around CMOS_READ(14 + addr). We also have some drivers
that call the low-level function directly:
arch/x86/include/asm/floppy.h: val = CMOS_READ(0x10) & 15;
arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port);
drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C);
drivers/input/misc/wistron_btns.c: qlen = CMOS_READ(cmos_address);
I suppose we could make the thinkpad driver do the same,
or provide a 'static inline' version of nvram_read_byte somewhere.
Arnd