From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH] char: nvram: disable on ARM
Date: Wed, 7 Feb 2018 02:55:09 +0100 [thread overview]
Message-ID: <20180207015509.GV3404@piout.net> (raw)
In-Reply-To: <CAK8P3a0Wmh6acO7W=weX37B2GNbecJQzPhZdVZcXXAwfT6jZ5A@mail.gmail.com>
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
next prev parent reply other threads:[~2018-02-07 1:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180206220534.9929-1-alexandre.belloni@bootlin.com>
2018-02-06 22:55 ` [PATCH] char: nvram: disable on ARM Arnd Bergmann
2018-02-07 1:55 ` Alexandre Belloni [this message]
2018-02-07 10:33 ` Arnd Bergmann
2018-02-07 12:48 ` Alexandre Belloni
2018-02-07 14:00 ` Arnd Bergmann
2018-02-07 15:47 ` Alexandre Belloni
2018-02-07 18:46 ` Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180207015509.GV3404@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).