On Tue, Apr 28, 2015 at 3:45 PM, Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> wrote: > 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. Of course if you can think of a more elegant way to handle this, by all means, please let us know. :) -- 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
