[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.03.1307171416490.14924@syhkavp.arg>
Date: Wed, 17 Jul 2013 14:29:02 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Russell King - ARM Linux <linux@....linux.org.uk>
cc: Pawel Moll <pawel.moll@....com>, Jon Medhurst <tixy@...aro.org>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
Samuel Ortiz <sameo@...ux.intel.com>,
Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Amit Kucheria <amit.kucheria@...aro.org>,
Olof Johansson <olof@...om.net>,
Achin Gupta <Achin.Gupta@....com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Russell King - ARM Linux wrote:
> On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> > The sanest location at this point might simply be
> > drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c
> > depending on whether or not more such driver glue is expected in the
> > vexpress future. No point putting "arm" in the path, especially if this
> > is later reused on arm64.
>
> You wouldn't be making that argument if it were arch/arm64 and arch/arm32 -
> you'd probably be arguing that "arm" made perfect sense.
Well... in a sense: yes. But in the end, having per arch directories
under drivers/ is silly. We already have per arch directories under
arch/already.
> Don't get too hung up on names please, it's really not worth the time
> and effort being soo pedantic, and being soo pedantic leads to "pointless
> churn" when someone comes along and wants to pedantically change the
> names because it no longer matches the users.
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."
In fact what we'd need at this point is
drivers/code_that_no_subsystem_maintainers_wants/. This is becoming
overly ridiculous.
Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists