Messages in this thread | | | Date | Sun, 8 Aug 2010 16:51:30 -0700 (PDT) | From | David Brownell <> | Subject | Re: [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
| |