Hi Rob, Indeed, I could do that if you think that's a better option. Andy however suggested to always register a pinctrl controller. Both options suits me. Let me know what option you want me to implement. Thanks, Clément ----- On 16 Dec, 2019, at 22:39, Rob Herring robh@xxxxxxxxxx wrote: > On Wed, Dec 04, 2019 at 02:52:59PM +0100, Clément Leger wrote: >> >> ----- On 4 Dec, 2019, at 13:45, Andy Shevchenko andy.shevchenko@xxxxxxxxx wrote: >> >> > On Wed, Dec 4, 2019 at 12:13 PM Clement Leger <cleger@xxxxxxxxx> wrote: >> >> >> >> Since the driver has been moved to pinctrl and now supports it, move the >> >> documentation into pinctrl folder. In the same time, add documentation >> >> for pinctrl properties such has snps,has-pinctrl and description of pin >> >> alternate functions. >> > >> >> +- snps,has-pinctrl : If present, register the pinctrl controller. >> > >> > I'm wondering why we can't always assume pin control? >> >> This hardware IP is configured when instantiated to include support for >> muxing. If configured without support, the registers will exists but won't >> configure anything. >> I guess that it's not really a problem but it will lead to unusable >> pin muxing. > > Can't you determine this by the presence of child nodes? > > Rob
