On Wed, Oct 8, 2014 at 1:36 AM, Mark Brown <broonie@xxxxxxxxxx> wrote: > On Tue, Oct 07, 2014 at 03:10:01PM +0200, Geert Uytterhoeven wrote: >> On Tue, Oct 7, 2014 at 2:38 PM, Mark Brown <broonie@xxxxxxxxxx> wrote: > >> > The fix here is to not allow 0 as a GPIO in the core code (which >> > should've been there already). > >> Unfortunately it's not there. > >> And it's not as simple as changing the definition of gpio_is_valid() >> (crash in gpio_get_value()): > >> 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. > >> Quoting Linus (https://lkml.org/lkml/2014/9/4/464): >> "Fixing the old global GPIO numberspace API is a waste of time IMO". > >> 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. -- 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
