linux-kernel - Re: [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111002212711.GC4506@opensource.wolfsonmicro.com>
Date:	Sun, 2 Oct 2011 22:27:11 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Liam Girdwood <lrg@...com>, alsa-devel@...a-project.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
	Dmitry Artamonow <mad_soft@...ox.ru>
Subject: Re: [PATCH 2/6] ASoC: codecs: AK4641 depends on GPIOLIB

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