On Thu, Jun 20, 2013 at 12:10 AM, Stephen Warren <swar...@wwwdotorg.org> wrote: > On 06/14/2013 09:42 AM, Heiko Stübner wrote:
>> diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt >> b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt > >> -low-power-mode - low power mode >> +low-power-enable - enable low power mode >> +low-power-disable - disable low power mode > > Hmmm. That's changing the binding definition. What if somebody already > wrote their device tree according previous definition? It's not merged so see it as alterations to a WIP in the turners workshop or something. > It seems to be that tri-states are preferable for pinctrl DT: > > no entry: do nothing > = 0: disable > = 1: enable Better with explict enable/disable strings instead of <0> or <1> I think, but the semantic effect would be the same I guess, the upside with *enable/*disable strings is that we do not have to handle cases like tristate = <2>; ... >> +Arguments for parameters: >> + >> +- bias-pull-up, -down and -pin-default take as optional argument 0 to >> disable >> + the pull, on hardware supporting it the pull strength in Ohm. bias-disable >> + will also disable any active pull. > > Does this agree with the latest definition of the kernel-internal > meaning of 0 for pull-up/down? No that is wrong. Heiko, care to fix this binding doc? >> +- input-schmitt takes as argument the adjustable hysteresis in a >> + driver-specific format >> + >> +- input-debounce takes the debounce time as argument or 0 to disable >> debouncing >> + >> +- power-source argument is the custom value describing the source to select >> + >> +- slew-rate takes as argument the target rate in a driver-specific format > > If those things have driver-specific (note: should be > DT-binding-specific, not driver-specific) values, then I'm not convinced > that having a generic parameter name for them is a good idea; it makes > things look the same when they aren't. By forcing each binding to > include the vendor prefix on those properties and hence define a custom > property name, you're making it clear that the semantics may be different. Hmmm I don't think they're used right now, let's deal with them when we have something to showcase them with. Patches to delete the unclear bindings will be considered... Yours, Linus Walleij _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
