Hello, On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Courbot wrote: > I should have replied one month ago, but if gpiolib is disabled, how > can we use gpiolib-like logic to check the existence of a GPIO? > > Having GPIO disabled means there is no GPIO support, including the > ability to look for GPIOs. -ENOSYS is a well-documented error-code > which meaning also applies to the gpio_*_optional functions (we don't > have support for the operation you requested). If a driver or > architecture really, really needs GPIO support they can require or > depend on CONFIG_GPIOLIB, and the problem goes away. If they can work > with and without gpiolib, then they should check for -ENOSYS when they > request GPIOs and behave accordingly. What whould be the right behaviour in your eyes? I hope it's not if (ret != -ENOSYS) return ret; /* continue and ignore error */ > Moving the interpretation of what the absence of gpiolib means down to > the GPIO functions themselves is actually what might lead consumers to > not know the result of their request. For this reason I would say that > -ENOSYS is appropriate here. Yeah, I fully agree. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
