On Wed, Dec 4, 2019 at 4:50 PM Clément Leger <cleger@xxxxxxxxx> wrote: > ----- On 4 Dec, 2019, at 13:43, Andy Shevchenko andy.shevchenko@xxxxxxxxx wrote: > > On Wed, Dec 4, 2019 at 12:12 PM Clement Leger <cleger@xxxxxxxxx> wrote: > > Can't you split adding pin control data to a separate patch? > > Yes even if the first one will not be buildable. It will. Just split it wisely. I'm preparing Intel Lynxpoint conversion (you may see the approach here [1]) and I stumbled over similar problem. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel.git/commit/?h=review-andy&id=ddbf10ea98c1c96de98fb5878ca0d0042e912f6a > > Can't we generate these lists dynamically? > > Indeed, these list could be dynamically generated. However, since they > can be shared between all pinctrl instances of this driver I thought > it was better to keep them common and simply restrict the number > of pins at pinctrl registration. But as I said, I can generate them if > you want. OK, let's wait for subsys maintainers to comment on this. > >> + ret = pinctrl_enable(port->pctl); > >> + if (ret) { > >> + dev_err(gpio->dev, "pinctrl enable failed\n"); > >> + return ret; > >> + } > > > > Not sure why it's needed at all. > > I saw a comment over "pinctrl_register" in pinctrl.h saying: > > /* Please use pinctrl_register_and_init() and pinctrl_enable() instead */ > > So I switched to pinctrl_register_and_init + pinctrl_enable. I read the code and do not see any evidence you have to use above. Do you plan to do something in between of those two calls? > > Can you use new callback for this? > > Do you mean the gpiochip add_pin_ranges callback ? > If so, I will look at it. I meant ->add_pin_ranges() which is part of GPIO chip structure. > >> - .name = "gpio-dwapb", > >> + .name = "pinctrl-dwapb", > > > > This will break existing users. > > Ok, I will revert that. You may fix users at the same time. Either fine with me. -- With Best Regards, Andy Shevchenko