lkml.org 
[lkml]   [2015]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectnvram and generic_nvram modules are problematic, was Re: [PATCH] arch: m68k: mac: misc.c: Remove some unused functions

On Sun, 4 Jan 2015, Geert Uytterhoeven wrote:

> On Sun, Jan 4, 2015 at 8:21 AM, Finn Thain <fthain@telegraphics.com.au> wrote:
> > On Thu, 1 Jan 2015, Rickard Strandqvist wrote:
> > > Removes some functions that are not used anywhere:
> > > mac_pram_write() mac_pram_read()
> >
> > ... I'd rather not remove all of this code. Better to finish the
> > implementation.
>
> Indeed.
>
> > Would it be acceptable to utilize drivers/char/generic_nvram.c and
> > CONFIG_GENERIC_NVRAM? This is the PowerMac PRAM driver but looks
> > generic enough that it may not need any modification for 68k Macs.
>
> Yes, that would be great.
>

Unfortunately, it seems to be unworkable.

The only user of generic_nvram is PPC32 (PPC64 could benefit though).
PPC32 uses the driver by defining both CONFIG_NVRAM and
CONFIG_GENERIC_NVRAM.

I tried to simplify this so that CONFIG_GENERIC_NVRAM would build
drivers/char/generic_nvram, while CONFIG_NVRAM would build
drivers/char/nvram, in order that it would become possible to have a
multi-platform kernel with both, either, or niether.

But that approach brings new problems:

- An m68k multi-platform kernel would need to contain both modules, and
both modules would need MODULE_ALIAS_MISCDEV(NVRAM_MINOR). This isn't
going to work. (It's likely that other platforms might also want to use
generic_nvram and the same problem would apply to x86 and ARM.)

- The misc device code in drivers/char/nvram is duplicated in
generic_nvram. To avoid this duplication, the nvram module could
leverage the generic_nvram module instead. This doesn't work either.
Systems like mine (Gentoo) have "alias char-major-10-144 nvram" in
/etc/modprobe.d/i386.conf, which means that accessing /dev/nvram causes
the wrong module to load.

In the end I concluded that the only plausible "generic" driver is
actually drivers/char/nvram itself. Otherwise it would be under an arch/
directory and not under drivers/.

So the nvram module should be the one with
MODULE_ALIAS_MISCDEV(NVRAM_MAJOR), and it should work on any architecture
that needs to use it. (Sure enough, drivers/char/generic_nvram lacks the
MODULE_ALIAS.)

So I believe that the solution is to eliminate drivers/char/generic_nvram
altogether, and move the architecture-specific code out of
drivers/char/nvram, so the nvram module can be re-used more easily. I
think that PPC32, PPC64 and m68k could readily re-use it.

Drivers themselves all test for CONFIG_NVRAM; never CONFIG_GENERIC_NVRAM.
This is another indication that the generic_nvram driver is surplus to
requirement.

The CONFIG_PROC_FS support (/proc/driver/nvram) in the drivers/char/nvram
module is inherently architecture-specific. I suspect that the
Atari-specific code should move to arch/m68k/atari/ and the x86-specific
code should move to arch/x86/.

I find the ARM support in drivers/char/nvram to be surprising, not to say
questionable. The /proc/driver/nvram implementation, given
defined(__arm__), decodes the NVRAM contents in exactly the same format as
when defined(__i386__) || defined(__x86_64__). Whereas, only MIPS and
PowerPC defconfigs set CONFIG_RTC_DRV_CMOS at all, and without that symbol
the driver will never be built for ARM. This raises the question, does
/proc/driver/nvram do anything useful on any ARM platforms?

Some guidance on this problem would be appreciated; all the approaches I
tried led to unsatisfactory compromises. I don't want to keep re-writing
these patches without a workable plan.

--


\
 
 \ /
  Last update: 2015-02-01 05:01    [W:0.081 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site