Hello, On Tue, Apr 28, 2015 at 12:31:37PM +0900, Alexandre Courbot wrote: > On Tue, Apr 28, 2015 at 12:21 AM, Uwe Kleine-König > <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > > On Thu, Apr 09, 2015 at 11:20:55AM +0900, Alexandre Courbot wrote: > >> 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. Ack. 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
