On Mon, May 30, 2011 at 12:18 AM, Mitch Bradley <wmb@xxxxxxxxxxxxx> wrote: > On 5/29/2011 8:11 PM, Grant Likely wrote: >> >> On Mon, May 30, 2011 at 11:38:27AM +0800, Mark Brown wrote: >>> >>> On Sun, May 29, 2011 at 08:11:34PM -0700, Olof Johansson wrote: >>>> >>>> On Fri, May 27, 2011 at 6:24 PM, Mark Brown >>> >>>>> This is a step back from the usability of the existing platform data - >>>>> the platform data uses a series of individually named GPIOs while this >>>>> uses an array of GPIO numbers with magic indexes. The fact that you >>>>> need comments explaining what the functions of the array elements are >>>>> is a bit of a red flag here. >>> >>>> Agreed, I had similar concerns with the sdhci bindings where it used a >>>> 3-element array of gpios instead of the previous named ones. I was >>>> told it's common practice to do it that way though? Seems like a step >>>> backwards to me. :( >>> >>> Interesting... what was the reasoning behind this? It's a definite >>> step backwards but it does explain my major concern with the new batch >>> of device tree patches. >> >> The binding for gpios was defined a few years ago and it is in fairly >> wide use within the powerpc sphere. The design followed the pattern >> established for specifying irqs, and in that regard satisfied the >> principle of least surprise. >> >> That said, it isn't a very large leap to go from a single 'gpios' >> property to allowing multiple named gpios properties with meaningful >> names, particularly if they are fully specified by the device >> binding, and they follow exactly the same binding semantics as the >> existing 'gpios' proprety (phandle + gpio specifier). >> >> Personally, I'm /cautious/ about saying okay to extending the binding, >> simply because once the extension is in use it is really hard to go >> back on it, but I cannot think of any reason why this particular case >> wouldn't be a good idea. Anyone have thoughts on this? Ben? Mitch? > > > I'm currently dealing with an SoC that has over a hundred GPIOs. Whatever we > choose, I think it should be able to handle an insane number of GPIOs > without getting any more cumbersome that is necessary. That's pretty common, and I don't think it will be a problem; either with the current binding, or the proposed extension. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- 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
