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    [W:0.024 / U:1.448 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site