On Tue, Feb 6, 2018 at 11:05 PM, Alexandre Belloni
[off-list ref] wrote:
quoted hunk
/dev/nvram was never meant to be used alongside the RTC CMOS driver from
drivers/rtc as it already expose the NVRAM through another interface..
Anyway, the last defconfig to enable it properly was removed in 2010 so
prevent ARM users from selecting it.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/char/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
The change looks good:
Acked-by: Arnd Bergmann <arnd@arndb.de>
but taking a closer look raises a few other points:
* arch/arm/kernel/time.c has this code
#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
/* this needs a better home */
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
#endif /* pc-style 'CMOS' RTC support */
That can be adapted now, or maybe we could move all definitions into
a common place (that needs some more planning).
* similarly, this line in nvram.c can be simplified:
#if defined(CONFIG_ATARI)
# define MACH ATARI
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) /* and ?? */
# define MACH PC
#else
# error Cannot build nvram driver for this machine configuration.
#endif
* GENERIC_NVRAM is not really generic, instead this seems to be the
chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while
64-bit powerpc (cell, maple, opal, pseries) use code from
arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks.
The nvram_64 code appears to be mostly a superset of the 32-bit
generic_nvram one.
* The code in drivers/char/nvram is not used at all when
GENERIC_NVRAM is set, and half the code in there is different
between x86 and atari.
* most of the external interface in include/linux/nvram.h is
unused, the rest tends to be architecture specific
* The procfs file appears to be completely useless on any 64-bit
x86 machine, this is what I see:
$ 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
Arnd
On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
* arch/arm/kernel/time.c has this code
#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
/* this needs a better home */
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
#endif /* pc-style 'CMOS' RTC support */
That can be adapted now, or maybe we could move all definitions into
a common place (that needs some more planning).
Yes, on arm, the rtc_lock is mostly there to please
drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
x86 and PPC specific.
If we can get rid of arch/powerpc/platforms/chrp/time.c and
arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
is x86 only.
* similarly, this line in nvram.c can be simplified:
#if defined(CONFIG_ATARI)
# define MACH ATARI
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) /* and ?? */
# define MACH PC
#else
# error Cannot build nvram driver for this machine configuration.
#endif
* GENERIC_NVRAM is not really generic, instead this seems to be the
chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while
64-bit powerpc (cell, maple, opal, pseries) use code from
arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks.
The nvram_64 code appears to be mostly a superset of the 32-bit
generic_nvram one.
* The code in drivers/char/nvram is not used at all when
GENERIC_NVRAM is set, and half the code in there is different
between x86 and atari.
* most of the external interface in include/linux/nvram.h is
unused, the rest tends to be architecture specific
* The procfs file appears to be completely useless on any 64-bit
x86 machine, this is what I see:
$ 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
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
[off-list ref] wrote:
On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
quoted
* arch/arm/kernel/time.c has this code
#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
/* this needs a better home */
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
#endif /* pc-style 'CMOS' RTC support */
That can be adapted now, or maybe we could move all definitions into
a common place (that needs some more planning).
Yes, on arm, the rtc_lock is mostly there to please
drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
x86 and PPC specific.
If we can get rid of arch/powerpc/platforms/chrp/time.c and
arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
is x86 only.
What about these:
arch/alpha/kernel/rtc.c: spin_lock(&rtc_lock);
arch/alpha/kernel/rtc.c: spin_unlock(&rtc_lock);
arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock);
arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock);
arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock);
arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock);
arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock);
Are they all obsolete?
quoted
* similarly, this line in nvram.c can be simplified:
#if defined(CONFIG_ATARI)
# define MACH ATARI
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) /* and ?? */
# define MACH PC
#else
# error Cannot build nvram driver for this machine configuration.
#endif
* GENERIC_NVRAM is not really generic, instead this seems to be the
chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while
64-bit powerpc (cell, maple, opal, pseries) use code from
arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks.
The nvram_64 code appears to be mostly a superset of the 32-bit
generic_nvram one.
* The code in drivers/char/nvram is not used at all when
GENERIC_NVRAM is set, and half the code in there is different
between x86 and atari.
* most of the external interface in include/linux/nvram.h is
unused, the rest tends to be architecture specific
* The procfs file appears to be completely useless on any 64-bit
x86 machine, this is what I see:
$ 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.
For drivers/video/fbdev/, these appear to all be for pre-x86
Apple Macintosh (m68k or powerpc).
Arnd
On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
[off-list ref] wrote:
quoted
On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
quoted
* arch/arm/kernel/time.c has this code
#if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
/* this needs a better home */
DEFINE_SPINLOCK(rtc_lock);
EXPORT_SYMBOL(rtc_lock);
#endif /* pc-style 'CMOS' RTC support */
That can be adapted now, or maybe we could move all definitions into
a common place (that needs some more planning).
Yes, on arm, the rtc_lock is mostly there to please
drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
x86 and PPC specific.
If we can get rid of arch/powerpc/platforms/chrp/time.c and
arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
is x86 only.
What about these:
arch/alpha/kernel/rtc.c: spin_lock(&rtc_lock);
arch/alpha/kernel/rtc.c: spin_unlock(&rtc_lock);
arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock);
arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock);
arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock);
arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock);
arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock);
Are they all obsolete?
Yes and no. For those architecture, the spinlock is only used to make
the driver compile. It is probably not actually needed or at least it
can be made local to the driver.
For alpha, I just realized I never sent a patch removing the spinlock
usage, I'll do that this cycle:
https://github.com/alexandrebelloni/linux/commit/e79e2a754a3a67f2d7e906bfda0042f9dcf66a0b
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 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.
For drivers/video/fbdev/, these appear to all be for pre-x86
Apple Macintosh (m68k or powerpc).
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
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 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
On 07/02/2018 at 15:00:04 +0100, Arnd Bergmann wrote:
On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni
[off-list ref] wrote:
quoted
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
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 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.
I guess we can do that, provided we take rtc_lock before using
CMOS_READ.
Thinking of it, I think this means we don't need the lock for powerpc as
nvram_read_byte doesn't take it. So I guess it is only needed on x86.
--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com
On 07/02/2018 at 16:47:00 +0100, Alexandre Belloni wrote:
quoted
quoted
quoted
quoted
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.