On Wed, Mar 9, 2016 at 11:27 AM, Rob Herring <robh@xxxxxxxxxx> wrote: > On Tue, Mar 8, 2016 at 9:53 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> - The "name" is what the line (pin) is named >> on the chip, or the name of the rail going out on the board, from the chip, >> so it is a producer name. > > Who/what uses this? The names[] in struct gpio_chip has been used for years to name the lines of the GPIO chips. The requirement coming from the community for userspace GPIO is about being able to name the lines on the producer side. One example is 96boards that want to consistently name lines on a header from the producer side across a set of boards, no matter what SoC is used. In their case the actual consumer is some one-off peripheral driven from userspace, so there (I expect) userspace will set up the label/consumer name eventually, if any. >> I named these "name" and "consumer" in the userspace ABI, I think >> I should take a round and rename it from "label" to "consumer" >> also inside the kernel to avoid confusion with this, because "label" >> in DT is going to be converted to "name" in the GPIOlib and >> then it also has something named "label" and that is another thing, >> argh! > > There is still confusion because DT label should be the consumer side, > not the SoC pin name. Oh I see what you mean. That is actually how it works with the hogs, it is setting the consumer side of things through gpiod_get(). > Then of course you could have 3 levels of names needed if you have SoC > pin, board connector pin, and mezzanine consumer. I don't think the distinction between pin and board connector is needed, if it is then the connector should have its own DT node and I suspect that would be overkill. I am atleast optimistically assuming that "name" will cover pin/rail/header name - whatever makes most sense - for a GPIO line producer. Linus Walleij -- 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
