On Wed, Oct 8, 2014 at 1:36 AM, Mark Brown [off-list ref] wrote:

On Tue, Oct 07, 2014 at 03:10:01PM +0200, Geert Uytterhoeven wrote:

quoted

On Tue, Oct 7, 2014 at 2:38 PM, Mark Brown [off-list ref] wrote:

quoted

quoted

The fix here is to not allow 0 as a GPIO in the core code (which
should've been there already).

quoted

Unfortunately it's not there.

quoted

And it's not as simple as changing the definition of gpio_is_valid()
(crash in gpio_get_value()):

quoted

    gpiochip_add: GPIOs 0..211 (r8a7740_pfc) failed to register
    sh-pfc pfc-r8a7740: failed to init GPIO chip, ignoring...
    sh-pfc pfc-r8a7740: r8a7740_pfc support registered
    Unable to handle kernel NULL pointer dereference at virtual address 0000004c

Right, obviously it's not going to work if the platform actually uses 0
as a valid GPIO.

quoted

Quoting Linus (https://lkml.org/lkml/2014/9/4/464):
"Fixing the old global GPIO numberspace API is a waste of time IMO".

quoted

Hence I've just sent a patch to initialize the GPIO numbers with -ENOENT.

I do think it's worth renumbering the platforms since it's *relatively*
little work per platform compared to completing the gpiod transition.

But transition to gpiod is the way to ultimately fix this issue, as
well as many others. Not to mention that renumbering GPIOs will
certainly make a few users of the GPIO sysfs (another abomination,
agreed) unhappy. I can only recommend switching drivers to gpiod when
such issues are spotted.