lkml.org 
[lkml]   [2010]   [Aug]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] mfd: add TPS6586x driver
> > I've left the GPIO code in the driver because of
> > * David prefers to keep GPIO part of MFD devices in
> the drivers/mfd ( [1] )
> I think that's arguable for many reasons. A
> couple of them being that there
> are already several MFD GPIO subdevices there
> and that at least one of those
> has been authored by David itself.
> So that's certainly not a generic assumption. David, I
> would agree that the
> gpio code from Mike below is small enough (although it's
> probaly going to grow
> over time...) to stay withing the MFD driver,

I'd certainly prefer that.


> but what's your "policy" for
> accepting/rejecting GPIO drivers
> in drivers/gpio/ ?

I prefer drivers/GPIO code to be standalone chips
and SOC/ASIC/MFD GPIO support to stick together.

Classic example: arch/arm/... almost every SOC
has its own GPIO support coupled with the rest
of its core code (GPIOs being widely used as IRQ
support, which is also core support).


I prefer not seeing support for one chip end up
scattered throughout the source tree. When one
of the "sub-drivers" is very complicated (audio
and video come to mind) I object less, but that
kind of scattering still seems worth avoiding.

Some of Intel's platform chips aren't supported in
what I'd call very clean ways -- they're scattered,
with GPIO fragments in drivers/gpio (where I would
rather they not live, but I have no current notion
of better homes, lacking one directory tying all of
those MFD/SOC/Southbridge/... things together.

- Dave


- Dave





\
 
 \ /
  Last update: 2010-08-09 01:53    [from the cache]
©2003-2011 Jasper Spaans