DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=pacbell.net;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type;
  b=YYI0JKWmDFDGoIapW9hMFRER5PUJpSm5SEDHzwomvSxe46aVuPIEpa2pJ/d2eXEtSbXiA2Wu5co1Px16o0XIwmKQawnV/FEd+uYnKpFTRumSzrGI4fun7jG+SEYB9h94AjzfW0mC28dctQ2v6KksGfh4i75nHibQtnaSF2uNxFo=;
Message-ID: <94927.80688.qm@web180312.mail.gq1.yahoo.com>
Date: Sun, 8 Aug 2010 16:51:30 -0700 (PDT)
From: David Brownell <david-b@pacbell.net>
Subject: Re: [PATCH v2] mfd: add TPS6586x driver
To: Mike Rapoport <mike.rapoport@gmail.com>,
        Samuel Ortiz <sameo@linux.intel.com>
Cc: Mike Rapoport <mike@compulab.co.il>, Jean Delvare <khali@linux-fr.org>,
        David Brownell <dbrownell@users.sourceforge.net>,
        linux-kernel@vger.kernel.org
In-Reply-To: <20100808222636.GC3480@sortiz-mobl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1757
Lines: 55

> > 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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/