From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB
Date: Sun, 2 Oct 2011 22:27:11 +0100 [thread overview]
Message-ID: <20111002212711.GC4506@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <2726393.3Oc3SrGyN4@wuerfel>
On Sun, Oct 02, 2011 at 10:53:24PM +0200, Arnd Bergmann wrote:
> On Sunday 02 October 2011 21:41:07 Mark Brown wrote:
> > No, gpiolib is one implementation of the GPIO API but if platforms want
> > to go and define their own that's currently OK (personally I think at
> Thanks for the explanation!
> Is there any other symbol that I can test then?
You shouldn't be testing anything - the client side GPIO API (which is
what this driver is using) is supposed to stub itself out when not in
use so drivers should just be able to use it without worrying about
dependencies. You didn't report the problem but I'd expect that
whatever you saw will be an issue in whatever platform you were trying
to build for (I'm guessing it hasn't provided gpio_request_one()),
though it could be a problem in the gpiolib stubs if that's being used.
> I noticed that a lot of places use 'depends on GPIOLIB' or
> '#ifdef CONFIG_GPIOLIB', are those usually wrong, too?
Checks for gpiolib in drivers providing GPIOs are sensible, if a
platform hasn't used gpiolib then it's generally not even got an
interface for drivers to provide GPIOs.
On the user side these are usually due to people making the sort of
changes you're making here due to a random build coverage issue - it
seems unfortunately common for people to just shove a dependency in
Kconfig when they run into a build coverage issue without looking at
what's going on. For a lot of the stuff you see on PCs it's going to
make sense but for some of the "service" APIs like GPIOs that are more
commonly used only in embedded contexts the use of the API is usually
completely optional (eg, in this case the driver is controlling power
and reset lines which could easily just be strapped in the hardware with
no soft control and are supplied as optional platform data) so for many
systems the driver is going to work completely happily without doing
anything with GPIOs.
Adding dependencies to all the users needlessly restricts which systems
can use the drivers. Adding ifdefs to the drivers is repetitive and
isn't great for legiblity, having the header stub itself out is simpler
and easier to use on the driver side.
next prev parent reply other threads:[~2011-10-02 21:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-02 20:27 [PATCH 0/6] ASoC fixes from ARM randconfig builds Arnd Bergmann
2011-10-02 20:27 ` [PATCH 1/6] ASoC: codecs/wm8682: use __devexit_p Arnd Bergmann
2011-10-02 20:36 ` Mark Brown
2011-10-02 20:28 ` [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB Arnd Bergmann
2011-10-02 20:41 ` Mark Brown
2011-10-02 20:53 ` Arnd Bergmann
2011-10-02 21:27 ` Mark Brown [this message]
2011-10-03 10:59 ` Arnd Bergmann
2011-10-03 13:45 ` Russell King - ARM Linux
2011-10-03 14:35 ` [alsa-devel] " Mark Brown
2011-10-03 14:47 ` Arnd Bergmann
2011-10-03 15:20 ` Mark Brown
2011-10-03 16:19 ` Arnd Bergmann
2011-10-03 16:34 ` Mark Brown
2011-10-02 20:28 ` [PATCH 3/6] ASoC: imx: eukrea_tlv320 needs i2c Arnd Bergmann
2011-10-02 20:49 ` Mark Brown
2011-10-02 20:28 ` [PATCH 4/6] ASoC: sh: use correct __iomem annotations Arnd Bergmann
2011-10-02 20:50 ` Mark Brown
2011-10-02 21:20 ` Arnd Bergmann
2011-10-02 20:28 ` [PATCH 5/6] ASoC: samsung: fix Kconfig dependencies Arnd Bergmann
2011-10-02 20:47 ` Mark Brown
2011-10-02 21:14 ` Arnd Bergmann
2011-10-02 21:29 ` Mark Brown
2011-10-03 6:48 ` [alsa-devel] " Sangbeom Kim
2011-10-03 11:50 ` Arnd Bergmann
2011-10-03 12:07 ` Mark Brown
2011-10-03 13:43 ` [PATCH 5/6] ASoC: samsung: wm8994 depends on mfd_wm8994 Arnd Bergmann
2011-10-03 14:08 ` Mark Brown
2011-10-03 14:35 ` [PATCH v3] " Arnd Bergmann
2011-10-03 14:40 ` Mark Brown
2011-10-02 20:28 ` [PATCH 6/6] ASoC: samsung: add missing __devexit_p() annotations Arnd Bergmann
2011-10-02 20:48 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20111002212711.GC4506@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).