On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > 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 */ If a consumer absolutely needs a GPIO (most of the drivers out there I believe), then -ENOSYS can be handled like any other error. If it doesn't, and the driver is fine without GPIO support as well (meaning that it can somehow work even if a GPIO is declared, but GPIO support is not compiled in), then it will need to explicitly handle that particular error. That case should be rare though - most drivers will want to propagate -ENOSYS. -- 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
