Hi Jean-Christophe,
On Sat, 7 Mar 2015 00:49:55 +0800
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@xxxxxxxxxxxx> wrote:
>
> > On Mar 6, 2015, at 11:08 PM, Nicolas Ferre <nicolas.ferre@xxxxxxxxx> wrote:
> >
> > Le 26/02/2015 10:34, Jean-Christophe PLAGNIOL-VILLARD a écrit :
> >> Today if we want to disable a pio bank we may will siliently break pinctrl
> >> configuration in the DT. This will be detected only at runtime.
> >>
> >> So move the pinctrl configuration to the bank instead of the bus.
> >> This allow to detect pinctrl issue at DT compiling time when disable a bank.
> >>
> >> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@xxxxxxxxxxxx>
> >> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
> >> Cc: devicetree@xxxxxxxxxxxxxxx
> >> ---
> >> .../bindings/pinctrl/atmel,at91-pinctrl.txt | 66 ++++++++++++++++++++++
> >> 1 file changed, 66 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> index b7a93e8..78355ee 100644
> >> --- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> +++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
> >> @@ -148,3 +148,69 @@ dbgu: serial@fffff200 {
> >> pinctrl-0 = <&pinctrl_dbgu>;
> >> status = "disabled";
> >> };
> >> +
> >> +II) New Bindings per PIO Block
> >
> > Sorry but NACK.
> >
> > I don't want to manage another flavor of the pinmux biding with no real
> > benefit. I would have been good if we had it from day-1. Now it's too late.
>
> yes we do, we catch but a compiling time instead of RUNTIME which is critical
>
> so I’ll pass on the NACK
Tell me, how can you pass on a NACK coming from the at91 maintainer
(which is also your co-maintainer) when you modify bindings of an at91
driver ?
Please let's try to be constructive here, so that we can find an
acceptable solution.
>
> >
> > Moreover, splitting a binding definition if you have a function given by
> > multiple banks can be weird and not well understood in regard to our
> > current group+function definition scheme (Cf. your last example).
> >
I don't think it's a good idea either: you'll have to split pinconf
definitions and that definitely doesn't improve readability.
>
> Others already do so and this is not complex at all
Could you point out these bindings (and real examples please).
Best Regards,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
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
