[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.03.1307171148160.14924@syhkavp.arg>
Date: Wed, 17 Jul 2013 11:57:55 -0400 (EDT)
From: Nicolas Pitre <nicolas.pitre@...aro.org>
To: Pawel Moll <pawel.moll@....com>
cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"devicetree-discuss@...ts.ozlabs.org"
<devicetree-discuss@...ts.ozlabs.org>,
Samuel Ortiz <sameo@...ux.intel.com>,
Olof Johansson <olof@...om.net>,
Amit Kucheria <amit.kucheria@...aro.org>,
Jon Medhurst <tixy@...aro.org>,
Achin Gupta <Achin.Gupta@....com>,
Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>
Subject: Re: [RFC PATCH v5 0/1] drivers: mfd: Versatile Express SPC support
On Wed, 17 Jul 2013, Pawel Moll wrote:
> On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> > On Wed, 17 Jul 2013, Pawel Moll wrote:
> >
> > > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > > If this is really miscelaneous code that really doesn't fit
> > > > anywhere else, it should rather go into drivers/misc/ as a last resort.
> > >
> > > Interestingly enough drivers/misc was my first choice for all the
> > > vexpress stuff, but it wasn't received well...
> > >
> > > Anyway, the SPC driver as it is now seem to be a "power management
> > > system driver". Maybe a relevant directory would be in place? Wouldn't
> > > PSCI belong there as well? (there are two psci.c files in arch/arm and
> > > arch/arm64, surprisingly similar ones ;-)
> > >
> > > The bottom line is: today it is not an MFD driver.
> >
> > But we know it will, right? So better save some churn by storing the
> > initial code where it would end up anyway once complete.
>
> Not in that form, no. The code living in mfd will just register
> mfd_cells while "functional" parts are going to live elsewhere. This is
> how I understand what Samuel asked me to do and that's what is happening
> to vexpress-sysreg now.
A drivers/pm/ or drivers/power/ could be created, but that implies sort
of a more defined subsystem with a common API and the SPC code doesn't
fit that as it is only providing services to actual drivers on top of
it.
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.
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