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.