All of lore.kernel.org
 help / color / mirror / Atom feed
From: sameo@linux.intel.com (Samuel Ortiz)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Date: Thu, 18 Jul 2013 00:47:29 +0200	[thread overview]
Message-ID: <20130717224729.GA20652@zurbaran> (raw)
In-Reply-To: <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>

On Wed, Jul 17, 2013 at 06:22:46PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Samuel Ortiz wrote:
> 
> > On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > > At this point I don't really care about the name.  I just want the damn 
> > > thing merged upstream.  But after several iterations to either fit one 
> > > or another maintainers taste, each rework ends up in that maintainer 
> > > saying: "Now that you've reworked the code, I still don't like it since 
> > > this no longer fits in my subsystem tree."
> > FWIW, we asked Pawel to rework the sysreg and config parts of the
> > vexpress driver, make it an actual MFD driver, and spread the remaining
> > bits of the code into their respective subsystems. I don't think
> > this is an eccentric requirement.
> 
> I agree.  However the code that Lorenzo just posted can't be deprived 
> of any more sysreg/config parts.  
Yes, and I appreciate Lorenzo's effort here.


> Even the larger code you reviewed before is completely useless without 
> _additional_ drivers to go on top which are indeed waiting after this 
> code to be merged before they are submitted to their respective 
> subsystems.
Right. And merging this code in the right place is exactly what we're
doing here.

 
> And those additional drivers are way more interesting than this dumb 
> register access arbitrator.  
Yes, they're a lot smarter hence the requirement to have them live into
their respective subsystems where the right maintainer can provide
relevant reviews on them.

> > I don't mind merging Lorenzo's SPC driver as it is if he can explain to
> > me how it will eventually evolve into an actual MFD driver. If that's
> > not the case, I don't see how I could justify merging it through the
> > MFD tree.
> 
> Maybe the misunderstanding is about what actually is a MFD driver.
That's possible. I agree it should be documented properly.

> So I'll follow existing precedents in the kernel and move Lorenzo's code 
> to drivers/platform/vexpress/.
Thanks for that.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

WARNING: multiple messages have this Message-ID (diff)
From: Samuel Ortiz <sameo@linux.intel.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Pawel Moll <pawel.moll@arm.com>, Jon Medhurst <tixy@linaro.org>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@arm.com>,
	"devicetree-discuss@lists.ozlabs.org"
	<devicetree-discuss@lists.ozlabs.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Amit Kucheria <amit.kucheria@linaro.org>,
	Olof Johansson <olof@lixom.net>,
	Achin Gupta <Achin.Gupta@arm.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
Date: Thu, 18 Jul 2013 00:47:29 +0200	[thread overview]
Message-ID: <20130717224729.GA20652@zurbaran> (raw)
In-Reply-To: <alpine.LFD.2.03.1307171758591.14924@syhkavp.arg>

On Wed, Jul 17, 2013 at 06:22:46PM -0400, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Samuel Ortiz wrote:
> 
> > On Wed, Jul 17, 2013 at 02:29:02PM -0400, Nicolas Pitre wrote:
> > > At this point I don't really care about the name.  I just want the damn 
> > > thing merged upstream.  But after several iterations to either fit one 
> > > or another maintainers taste, each rework ends up in that maintainer 
> > > saying: "Now that you've reworked the code, I still don't like it since 
> > > this no longer fits in my subsystem tree."
> > FWIW, we asked Pawel to rework the sysreg and config parts of the
> > vexpress driver, make it an actual MFD driver, and spread the remaining
> > bits of the code into their respective subsystems. I don't think
> > this is an eccentric requirement.
> 
> I agree.  However the code that Lorenzo just posted can't be deprived 
> of any more sysreg/config parts.  
Yes, and I appreciate Lorenzo's effort here.


> Even the larger code you reviewed before is completely useless without 
> _additional_ drivers to go on top which are indeed waiting after this 
> code to be merged before they are submitted to their respective 
> subsystems.
Right. And merging this code in the right place is exactly what we're
doing here.

 
> And those additional drivers are way more interesting than this dumb 
> register access arbitrator.  
Yes, they're a lot smarter hence the requirement to have them live into
their respective subsystems where the right maintainer can provide
relevant reviews on them.

> > I don't mind merging Lorenzo's SPC driver as it is if he can explain to
> > me how it will eventually evolve into an actual MFD driver. If that's
> > not the case, I don't see how I could justify merging it through the
> > MFD tree.
> 
> Maybe the misunderstanding is about what actually is a MFD driver.
That's possible. I agree it should be documented properly.

> So I'll follow existing precedents in the kernel and move Lorenzo's code 
> to drivers/platform/vexpress/.
Thanks for that.

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/

  reply	other threads:[~2013-07-17 22:47 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-16 16:05 [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support Lorenzo Pieralisi
2013-07-16 16:05 ` Lorenzo Pieralisi
2013-07-16 16:05 ` [RFC PATCH v5 1/1] drivers: mfd: vexpress: add Serial Power Controller (SPC) support Lorenzo Pieralisi
2013-07-16 16:05   ` Lorenzo Pieralisi
2013-07-16 16:05   ` Lorenzo Pieralisi
2013-07-16 20:05   ` Rob Herring
2013-07-16 20:05     ` Rob Herring
2013-07-16 23:32     ` Nicolas Pitre
2013-07-16 23:32       ` Nicolas Pitre
2013-07-17  3:26 ` [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support Nicolas Pitre
2013-07-17  3:26   ` Nicolas Pitre
2013-07-17  3:26   ` Nicolas Pitre
2013-07-17  9:18 ` Pawel Moll
2013-07-17  9:18   ` Pawel Moll
2013-07-17 10:44   ` Lorenzo Pieralisi
2013-07-17 10:44     ` Lorenzo Pieralisi
2013-07-17 12:33   ` Nicolas Pitre
2013-07-17 12:33     ` Nicolas Pitre
2013-07-17 13:29     ` Pawel Moll
2013-07-17 13:29       ` Pawel Moll
2013-07-17 14:16       ` Nicolas Pitre
2013-07-17 14:16         ` Nicolas Pitre
2013-07-17 14:20         ` Pawel Moll
2013-07-17 14:20           ` Pawel Moll
2013-07-17 15:57           ` Nicolas Pitre
2013-07-17 15:57             ` Nicolas Pitre
2013-07-17 17:00             ` Russell King - ARM Linux
2013-07-17 17:00               ` Russell King - ARM Linux
2013-07-17 17:00               ` Russell King - ARM Linux
2013-07-17 18:29               ` Nicolas Pitre
2013-07-17 18:29                 ` Nicolas Pitre
2013-07-17 21:23                 ` Samuel Ortiz
2013-07-17 21:23                   ` Samuel Ortiz
2013-07-17 22:22                   ` Nicolas Pitre
2013-07-17 22:22                     ` Nicolas Pitre
2013-07-17 22:22                     ` Nicolas Pitre
2013-07-17 22:47                     ` Samuel Ortiz [this message]
2013-07-17 22:47                       ` Samuel Ortiz
2013-07-17 21:10           ` Samuel Ortiz
2013-07-17 21:10             ` Samuel Ortiz
2013-07-17 21:10             ` Samuel Ortiz
2013-07-17 21:07 ` Samuel Ortiz
2013-07-17 21:07   ` Samuel Ortiz
2013-07-17 21:07   ` Samuel Ortiz
2013-07-18  9:28   ` Lorenzo Pieralisi
2013-07-18  9:28     ` Lorenzo Pieralisi
2013-07-18  9:28     ` Lorenzo Pieralisi

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=20130717224729.GA20652@zurbaran \
    --to=sameo@linux.intel.com \
    --cc=linux-arm-kernel@lists.infradead.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.