On Tue, Jan 21, 2014 at 4:11 AM, Alexandre Courbot <gnurou@xxxxxxxxx> wrote: > On Sat, Jan 18, 2014 at 8:11 AM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: >> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 0); >> gpio = devm_gpiod_get_index(&pdev->dev, NULL, 1); >> >> Heikki, are you OK with this change? >> >> I think this is actually necessary if the ACPI and DT unification >> pipe dream shall limp forward, we cannot have arguments passed >> that have a semantic effect on DT but not on ACPI... Drivers >> that are supposed to use both ACPI and DT will always >> have to pass NULL as con ID. > > I agree that's how it should be be done with the current API if your > driver can obtain GPIOs from both ACPI and DT. This is a potential > issue, as drivers are not supposed to make assumptions about who is > going to be their GPIO provider. Let's say you started a driver with > only DT in mind, and used gpio_get(dev, con_id) to get your GPIOs. DT > bindings are thus of the form "con_id-gpio = <phandle>", and set in > stone. Then later, someone wants to use your driver with ACPI. How do > you handle that gracefully? Short answer is you can't. You have to pour backward-compatibility code into the driver first checking for that property and then falling back to the new binding if it doesn't exist. > I'm starting to wonder, now that ACPI is a first-class GPIO provider, > whether we should not start to encourage the deprecation of the > "con_id-gpio = <phandle>" binding form in DT and only use a single > indexed GPIO property per device. You have a valid point. > The con_id parameter would then only > be used as a label, which would also have the nice side-effect that > all GPIOs used for a given function will be reported under the same > name no matter what the GPIO provider is. As discussed earlier in this thread I'm not sure the con_id is suitable for labelling GPIOs. It'd be better to have a proper name specified in DT/ACPI instead. > From an aesthetic point of view, I definitely prefer using con_id to > identify GPIOs instead of indexes, but I don't see how we can make it > play nice with ACPI. Thoughts? Let's ask the DT maintainers... I'm a bit sceptic to the whole ACPI-DT-API-should-be-unified just-one-function-call business, as this was just a very simple example of what can happen to something as simple as devm_gpiod_get[_index](). Yours, 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
