On Fri, Feb 5, 2010 at 1:50 PM, Anton Vorontsov <[email protected]> wrote: > OF GPIO infrastructure is using dynamic GPIO bases, so it is possible > that of_get_gpio()'s returned GPIO number will be no longer valid, or > worse, it may point to an unexpected GPIO controller. > > This scenario is possible: > > driver A: driver B: driver C: > --------- --------- --------- > gpiochip_add() > gpio = of_get_gpio() > gpiochip_remove() > gpiochip_add() > gpio_request(gpio); > gpio_set_value(gpio); > > That is, driver A assumes that it is working with GPIO from driver B, > but in practice it may disappear and driver C will take its GPIO base > number, so it will provide the same GPIO numbers. > > With this patch that situation is no longer possible. Though drivers > will need to learn to put GPIOs back, so that GPIO controllers could > be removed. > > Signed-off-by: Anton Vorontsov <[email protected]>
Rather than having a lock at the device tree data pointer level which mixes usage with potentially many other drivers; wouldn't it make more sense to use a mutex at the of_gc subsystem context? g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
