Hi Jean-Christophe, On Sat, 7 Mar 2015 00:49:55 +0800 Jean-Christophe PLAGNIOL-VILLARD <[email protected]> wrote:
> > > On Mar 6, 2015, at 11:08 PM, Nicolas Ferre <[email protected]> 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 <[email protected]> > >> Cc: Linus Walleij <[email protected]> > >> Cc: [email protected] > >> --- > >> .../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 [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
