The producer side works fine as-is, agreed.
+1
What I was not sure about was the use of having an array of unnamed
gpios as part of the consumer-side binding, where there's no logical
ordering between these entries.
In the sdhci case, there are three gpios; one to supply power to the
slot;
one for card detect and one for write protect sense.
In that case, it would make a whole lot more sense to have three
separate
properties, say "power-gpio", "cd-gpio" and "wp-gpio", than an opaque
array of
entries without description besides what comments are used in the dts
file.
Yes. And this way you can also show a specific board doesn't have a
specific function GPIO wired up by simply not having the property for
it, instead of that ugly 0 phandle business.
That these in turn point just to gpio number <x> at controller <y> is
OK with
me.
Controller <y> GPIO # <x> with flags <w>, yes. A generic "GPIO
specifier".
Also, I can see cases where it makes sense to have more than one gpio
references in a property (i.e. busses), but only where there's either
internal
ordering to them, or where ordering doesn't matter at all.
That's up to the device binding, let's hope the people who write those
show good judgement :-)
Segher
--
To unsubscribe from this list: send the line "unsubscribe linux-tegra" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
