On Wed, Mar 22, 2017 at 12:54 PM, Gregory CLEMENT <gregory.clement@xxxxxxxxxxxxxxxxxx> wrote: > On ven., déc. 30 2016, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >>> + mask = BIT(offset); >>> + >>> + regmap_read(info->regmap, reg, &val); >>> >>> + return (val & mask) == 0; >> >> Use this: >> >> return !(val & mask); > > done but I could tou explain the advantage of doing it? The other controllers do it so makes the code easier to perceptualize. >>> + ret = gpiochip_add_pin_range(&info->gpio_chip, dev_name(dev), 0, >>> + pinbase, info->data->nr_pins); >>> + if (ret) >>> + return ret; >> >> Why do you do this? >> >> Why not just put the ranges into the device tree? We already support >> this in the gpiolib core and it is helpful. >> >> See Documentation/devicetree/bindings/gpio/gpio.txt >> and other DTS files for gpio-ranges. > > Following your review, I tried to use it but it didn't work for > me. When the second pin controller was probed then there was collision > for the gpio number. I tried several combination without any luck. That sounds like a bug. Are you using dynamic GPIO number assignments? Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html