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:3.719 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site