From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
linux-fbdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-scsi@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, Joshua Thompson <funaho@jurai.org>
Subject: Re: [PATCH v9 00/22] Re-use nvram module
Date: Tue, 22 Jan 2019 09:22:34 +0000 [thread overview]
Message-ID: <20190122092234.GA15813@kroah.com> (raw)
In-Reply-To: <cover.1547525936.git.fthain@telegraphics.com.au>
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> /dev/nvram misc device. This module is used only by 32-bit PowerPC
> platforms.
>
> The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
> /dev/nvram misc device. This module is now used only by x86 and m68k
> thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
>
> The "generic" module cannot be used by x86 or m68k platforms because it
> cannot co-exist with the "CMOS" module. One reason for that is the
> CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
> that automatically loading the appropriate module would be impossible
> because only one module can provide the char-major-10-144 alias.
>
> A multi-platform kernel binary needs a single, generic module. With this
> patch series, drivers/char/nvram.c becomes more generic and some of the
> arch-specific code gets moved under arch/. The nvram module is then
> usable by all m68k, powerpc and x86 platforms.
>
> This allows for removal of drivers/char/generic_nvram.c as well as a
> duplicate 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 approach reduces inconsistencies between PPC32 and PPC64 and also
> 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 any
> bootloader that works across the various platforms having XPRAM
> (e.g. Emile).
>
> This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
> 64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
> pSeries or CHRP.
>
> I think there are two possible merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively,
> the m68k maintainer could take patches 1 thru 16 (though some of these
> have nothing to do with m68k) and after those patches reach mainline
> the powerpc maintainer could take 17 thru 22.
I just took the whole series, thanks for doing this, looks good.
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
linux-fbdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-scsi@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, Joshua Thompson <funaho@jurai.org>
Subject: Re: [PATCH v9 00/22] Re-use nvram module
Date: Tue, 22 Jan 2019 10:22:34 +0100 [thread overview]
Message-ID: <20190122092234.GA15813@kroah.com> (raw)
In-Reply-To: <cover.1547525936.git.fthain@telegraphics.com.au>
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> /dev/nvram misc device. This module is used only by 32-bit PowerPC
> platforms.
>
> The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
> /dev/nvram misc device. This module is now used only by x86 and m68k
> thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
>
> The "generic" module cannot be used by x86 or m68k platforms because it
> cannot co-exist with the "CMOS" module. One reason for that is the
> CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
> that automatically loading the appropriate module would be impossible
> because only one module can provide the char-major-10-144 alias.
>
> A multi-platform kernel binary needs a single, generic module. With this
> patch series, drivers/char/nvram.c becomes more generic and some of the
> arch-specific code gets moved under arch/. The nvram module is then
> usable by all m68k, powerpc and x86 platforms.
>
> This allows for removal of drivers/char/generic_nvram.c as well as a
> duplicate 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 approach reduces inconsistencies between PPC32 and PPC64 and also
> 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 any
> bootloader that works across the various platforms having XPRAM
> (e.g. Emile).
>
> This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
> 64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
> pSeries or CHRP.
>
> I think there are two possible merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively,
> the m68k maintainer could take patches 1 thru 16 (though some of these
> have nothing to do with m68k) and after those patches reach mainline
> the powerpc maintainer could take 17 thru 22.
I just took the whole series, thanks for doing this, looks good.
greg k-h
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Finn Thain <fthain@telegraphics.com.au>
Cc: Michael Schmitz <schmitzmic@gmail.com>,
linux-fbdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-scsi@vger.kernel.org, linux-m68k@lists.linux-m68k.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Paul Mackerras <paulus@samba.org>,
linuxppc-dev@lists.ozlabs.org, Joshua Thompson <funaho@jurai.org>
Subject: Re: [PATCH v9 00/22] Re-use nvram module
Date: Tue, 22 Jan 2019 10:22:34 +0100 [thread overview]
Message-ID: <20190122092234.GA15813@kroah.com> (raw)
In-Reply-To: <cover.1547525936.git.fthain@telegraphics.com.au>
On Tue, Jan 15, 2019 at 03:18:56PM +1100, Finn Thain wrote:
> The "generic" NVRAM module, drivers/char/generic_nvram.c, implements a
> /dev/nvram misc device. This module is used only by 32-bit PowerPC
> platforms.
>
> The RTC "CMOS" NVRAM module, drivers/char/nvram.c, also implements a
> /dev/nvram misc device. This module is now used only by x86 and m68k
> thanks to commit 3ba9faedc180 ("char: nvram: disable on ARM").
>
> The "generic" module cannot be used by x86 or m68k platforms because it
> cannot co-exist with the "CMOS" module. One reason for that is the
> CONFIG_GENERIC_NVRAM kludge in drivers/char/Makefile. Another reason is
> that automatically loading the appropriate module would be impossible
> because only one module can provide the char-major-10-144 alias.
>
> A multi-platform kernel binary needs a single, generic module. With this
> patch series, drivers/char/nvram.c becomes more generic and some of the
> arch-specific code gets moved under arch/. The nvram module is then
> usable by all m68k, powerpc and x86 platforms.
>
> This allows for removal of drivers/char/generic_nvram.c as well as a
> duplicate 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 approach reduces inconsistencies between PPC32 and PPC64 and also
> 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 any
> bootloader that works across the various platforms having XPRAM
> (e.g. Emile).
>
> This patch series was tested on Atari, Mac, PowerMac (both 32-bit and
> 64-bit) and ThinkPad hardware. AFAIK, it has not yet been tested on
> pSeries or CHRP.
>
> I think there are two possible merge strategies for this patch series.
> The char misc maintainer could take the entire series. Alternatively,
> the m68k maintainer could take patches 1 thru 16 (though some of these
> have nothing to do with m68k) and after those patches reach mainline
> the powerpc maintainer could take 17 thru 22.
I just took the whole series, thanks for doing this, looks good.
greg k-h
next prev parent reply other threads:[~2019-01-22 9:22 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 4:18 [PATCH v9 00/22] Re-use nvram module Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` [PATCH v9 21/22] char/generic_nvram: Remove as unused Finn Thain
2019-01-15 4:18 ` [PATCH v9 08/22] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain
2019-01-15 4:18 ` [PATCH v9 09/22] char/nvram: Implement NVRAM read/write methods Finn Thain
2019-01-15 4:18 ` [PATCH v9 06/22] powerpc: Replace nvram_* extern declarations with standard header Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` [PATCH v9 04/22] nvram: Replace nvram_* function exports with static functions Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` [PATCH v9 03/22] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain
2019-01-15 4:18 ` [PATCH v9 20/22] powerpc: Enable HAVE_ARCH_NVRAM_OPS and disable GENERIC_NVRAM Finn Thain
2019-01-15 4:18 ` [PATCH v9 11/22] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain
2019-01-15 4:18 ` [PATCH v9 16/22] char/nvram: Add "devname:nvram" module alias Finn Thain
2019-01-15 4:18 ` [PATCH v9 14/22] macintosh/via-cuda: Don't rely on Cuda to end a transfer Finn Thain
2019-01-15 4:18 ` [PATCH v9 18/22] powerpc: Implement nvram ioctls Finn Thain
2019-01-15 4:18 ` [PATCH v9 02/22] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain
2019-01-15 4:18 ` [PATCH v9 07/22] char/nvram: Adopt arch_nvram_ops Finn Thain
2019-01-15 4:18 ` [PATCH v9 13/22] m68k/mac: Fix PRAM accessors Finn Thain
2019-01-15 4:18 ` [PATCH v9 22/22] powerpc: Adopt nvram module for PPC64 Finn Thain
2019-01-15 4:18 ` [PATCH v9 19/22] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC Finn Thain
2019-01-15 4:18 ` [PATCH v9 19/22] powerpc, fbdev: Use NV_CMODE and NV_VMODE only when CONFIG_PPC32 && CONFIG_PPC_PMAC && CONFIG_NVRAM Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-15 4:18 ` [PATCH v9 17/22] powerpc: Define missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain
2019-01-15 4:18 ` [PATCH v9 15/22] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain
2019-01-22 9:19 ` Greg Kroah-Hartman
2019-01-22 9:22 ` Greg Kroah-Hartman
2019-01-15 4:18 ` [PATCH v9 05/22] m68k/atari: Implement arch_nvram_ops struct Finn Thain
2019-01-15 4:18 ` [PATCH v9 10/22] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2019-01-15 4:18 ` [PATCH v9 12/22] m68k/mac: Use macros for RTC accesses not magic numbers Finn Thain
2019-01-15 4:18 ` [PATCH v9 01/22] scsi/atari_scsi: Don't select CONFIG_NVRAM Finn Thain
2019-01-15 4:18 ` Finn Thain
2019-01-22 9:22 ` Greg Kroah-Hartman [this message]
2019-01-22 9:22 ` [PATCH v9 00/22] Re-use nvram module Greg Kroah-Hartman
2019-01-22 9:22 ` Greg Kroah-Hartman
2019-01-22 22:06 ` Finn Thain
2019-01-22 22:06 ` Finn Thain
2019-01-22 22:06 ` Finn Thain
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=20190122092234.GA15813@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=fthain@telegraphics.com.au \
--cc=funaho@jurai.org \
--cc=geert@linux-m68k.org \
--cc=jejb@linux.ibm.com \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=martin.petersen@oracle.com \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=schmitzmic@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.