Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <cover.1545784679.git.fthain@telegraphics.com.au>
In-Reply-To: <cover.1545784679.git.fthain@telegraphics.com.au>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Sat, 29 Dec 2018 23:45:36 +0100
Message-ID: <CAK8P3a3yF+CkvQS_funp4BPhi-10N4yse2oAeWAcWR+Ty5Pxmg@mail.gmail.com>
Subject: Re: [PATCH v8 00/25] Re-use nvram module
To:     Finn Thain <fthain@telegraphics.com.au>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        linux-m68k <linux-m68k@lists.linux-m68k.org>,
        linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Dec 26, 2018 at 1:43 AM Finn Thain <fthain@telegraphics.com.au> wrote:

> This allows for removal of drivers/char/generic_nvram.c as well as some
> duplicated code in arch/powerpc/kernel/nvram_64.c. By reducing the number
> of /dev/nvram char misc device implementations, the number of bugs and
> inconsistencies is also reduced.
>
> This patch series reduces inconsistencies between PPC32 and PPC64, and
> between PPC_PMAC and MAC. A uniform API has benefits for userspace.
> For example, some error codes for some ioctl calls become consistent
> across PowerPC platforms. The uniform API can potentially benefit
> bootloaders that work across different platforms which all have XPRAM
> (e.g. Emile).
>
> I think there are two reasonable merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively the
> m68k maintainer could take patches 1 thru 14, and after those patches
> reach mainline the powerpc maintainer could take 15 thru 25 (even though
> patch 21 is not powerpc-related).

I had a look at the complete series now, and I think this is a great cleanup.
I replied with a couple of minor comments that you may or may not want
to address first.

The one thing I would like to see resolved (I hope this doesn't bring
back an old discussion you had already concluded) is regarding
the use of a global exported structure of function pointers, as opposed
to using either directly exported functions (with a consistent interface)
or a boot-time selectable structure like dma_map_ops or ppc_md.

    Arnd