All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Thain <fthain@telegraphics.com.au>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	linux-m68k <linux-m68k@vger.kernel.org>,
	linuxppc-dev <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [RFC v4 00/25] Re-use nvram module
Date: Tue, 14 Jul 2015 17:57:35 +1000 (AEST)	[thread overview]
Message-ID: <alpine.LNX.2.00.1507141045020.24654@nippy.intranet> (raw)
In-Reply-To: <CAMuHMdX+5XHWf3sVqAnF_mioS1zZmxQXurEeMGMM3OKa9acxhA@mail.gmail.com>


On Mon, 13 Jul 2015, Geert Uytterhoeven wrote:

> 
> How are we gonna merge this?

I think the series would have to be merged almost whole. For the most 
part, no maintainer can merge any of this without ACKs from others:

- to improve code re-use by replacing an API shared by arch-specific code 
  and a variety of drivers means getting ACKs from everyone concerned (or 
  the old API can't be removed).

- to move arch-specific code out of a generic driver means getting ACKs 
  from both arch maintainer and driver maintainer. Some of this 
  arch-specific code is shared by m68k, x86 and arm (but not powerpc) and 
  this complicates things.

- to adopt a new Kconfig convention in a uniform and consistent way seems 
  to require simultaneous changes in various drivers and architectures.

> Have you looked into the dependencies?

What I saw was not pretty.

> Are there (large) parts we can merge in parallel?

Not AFAICT. Two patches could be cherry picked, that might make sense to 
merge by themselves. Those are patches 2 and 12. Either or both could be 
reviewed and merged by the char device maintainers.

There are a couple of other small patches that could probably be cherry 
picked without breaking anything but these changes are not justified 
except by subsequent patches.

> 
> Thanks again!

No worries.

-- 

> 
> Gr{oetje,eeting}s,
> 
>                         Geert
> 

      reply	other threads:[~2015-07-14  7:57 UTC|newest]

Thread overview: 115+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-12 10:25 [RFC v4 00/25] Re-use nvram module Finn Thain
2015-07-12 10:25 ` Finn Thain
2015-07-12 10:25 ` [RFC v4 01/25] scsi/atari_scsi: Dont select CONFIG_NVRAM Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 02/25] char/nvram: Use bitwise OR to obtain Atari video mode data Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 03/25] m68k/atari: Move Atari-specific code out of drivers/char/nvram.c Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-13 18:13   ` Andreas Schwab
2015-07-13 18:13     ` Andreas Schwab
2015-07-14  8:17     ` Finn Thain
2015-07-14  8:23       ` Geert Uytterhoeven
2015-07-14  8:33         ` Andreas Schwab
2015-07-14  8:33           ` Andreas Schwab
2015-07-22  3:52       ` Michael Schmitz
2015-07-22  4:22         ` Finn Thain
2015-07-22 14:32           ` Christian T. Steigies
2015-07-22 23:46             ` Michael Schmitz
2015-07-23  0:49               ` Finn Thain
2015-07-23  9:21           ` Christian T. Steigies
2015-07-24  2:56             ` Michael Schmitz
2015-07-24 19:07               ` Christian T. Steigies
2015-07-25  0:35                 ` Finn Thain
2015-07-25  1:00                   ` Michael Ellerman
2015-07-25  7:38                     ` Finn Thain
2015-07-26  1:37                     ` Finn Thain
2015-07-25  0:51                 ` Michael Schmitz
2015-07-25  7:27                   ` Finn Thain
2015-07-26  1:02                     ` Michael Schmitz
2015-07-26  1:19                       ` Finn Thain
2015-07-27  2:23                         ` Michael Schmitz
2015-07-27  5:51                           ` Finn Thain
2015-07-12 10:25 ` [RFC v4 04/25] m68k/atari: Replace nvram_{read,write}_byte with arch_nvram_ops Finn Thain
2015-07-12 10:25   ` [RFC v4 04/25] m68k/atari: Replace nvram_{read, write}_byte " Finn Thain
2015-07-12 10:25   ` [RFC v4 04/25] m68k/atari: Replace nvram_{read,write}_byte " Finn Thain
2015-07-12 10:25 ` [RFC v4 05/25] char/nvram: Re-order functions to remove forward declarations and #ifdefs Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 06/25] char/nvram: Adopt arch_nvram_ops Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 07/25] x86/thinkpad_acpi: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 08/25] char/nvram: Allow the set_checksum and initialize ioctls to be omitted Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 09/25] char/nvram: Implement NVRAM read/write methods Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 10/25] char/nvram: Use generic fixed_size_llseek() Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 11/25] m68k/atari: Implement arch_nvram_ops methods and enable CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 12/25] char/nvram: Add "devname:nvram" module alias Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 13/25] powerpc: Cleanup nvram includes Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 14/25] powerpc: Add missing ppc_md.nvram_size for CHRP and PowerMac Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 15/25] powerpc: Implement arch_nvram_ops.get_size() and remove old nvram_* exports Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 16/25] powerpc: Implement nvram sync ioctl Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_wri Finn Thain
2015-07-12 10:25   ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-14  7:58   ` Finn Thain
2015-07-14  7:58     ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Finn Thain
2015-07-14 11:52     ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Benjamin Herrenschmidt
2015-07-14 11:52       ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Benjamin Herrenschmidt
2015-07-15  5:21       ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-15  5:21         ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Finn Thain
2015-07-16  6:01         ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-07-16  6:01           ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Finn Thain
2015-09-18  8:17           ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram_write_byte() Finn Thain
2015-09-18  8:17             ` [RFC v4 17/25] powerpc, fbdev: Use arch_nvram_ops methods instead of nvram_read_byte() and nvram Finn Thain
2015-07-12 10:25 ` [RFC v4 18/25] nvram: Drop nvram_* symbol exports and prototypes Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 19/25] powerpc: Remove CONFIG_GENERIC_NVRAM and adopt CONFIG_HAVE_ARCH_NVRAM_OPS Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 20/25] char/generic_nvram: Remove as unused Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 21/25] powerpc: Adopt nvram module for PPC64 Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 22/25] m68k/mac: Adopt naming and calling conventions for PRAM routines Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 23/25] m68k/mac: Use macros for RTC accesses not magic numbers Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 24/25] m68k/mac: Fix PRAM accessors Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25 ` [RFC v4 25/25] m68k: Dispatch nvram_ops calls to Atari or Mac functions Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-12 10:25   ` Finn Thain
2015-07-13  7:55 ` [RFC v4 00/25] Re-use nvram module Geert Uytterhoeven
2015-07-14  7:57   ` Finn Thain [this message]

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=alpine.LNX.2.00.1507141045020.24654@nippy.intranet \
    --to=fthain@telegraphics.com.au \
    --cc=geert@linux-m68k.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-m68k@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 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.