On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni <alexandre.bell...@bootlin.com> wrote: > On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote: >> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
>> >> $ 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 installed >> >> >> > >> > 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. 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