On Sunday, October 05, 2014 07:36:04 PM Alexandre Courbot wrote:
> On Wed, Oct 1, 2014 at 5:03 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> > On Wednesday 01 October 2014 04:12:41 Rafael J. Wysocki wrote:
> >> + static const char * const suffixes[] = { "gpios", "gpio" };
> >> + struct acpi_device *adev = ACPI_COMPANION(dev);
> >> struct acpi_gpio_info info;
> >> struct gpio_desc *desc;
> >> + char propname[32];
> >> + int i;
> >>
> >> - desc = acpi_get_gpiod_by_index(dev, idx, &info);
> >> - if (IS_ERR(desc))
> >> - return desc;
> >> + /* Try first from _DSD */
> >> + for (i = 0; i < ARRAY_SIZE(suffixes); i++) {
> >> + if (con_id && strcmp(con_id, "gpios")) {
> >> + snprintf(propname, sizeof(propname), "%s-%s",
> >> + con_id, suffixes[i]);
> >> + } else {
> >> + snprintf(propname, sizeof(propname), "%s",
> >> + suffixes[i]);
> >> + }
> >
> > The general interface seems fine, but I'd be happier if you didn't
> > try to support all four of the possible syntaxes we have in DT.
> > It would be much better to have only "gpios" and not "gpio", and
> > the "foo-gpios" syntax should be replaced with whatever method you
> > use to name other subsystem specific links. For most subsystems
> > we now use something like "gpio-names", but unfortunately the GPIO
> > binding goes back to the time before we had come to that agreement.
> > The same applies to regulators.
>
> Wouldn't restricting the naming scheme cause problems for ACPI drivers
> that want to reuse existing DT bindings? Since DT bindings are set in
> stone, this means we would have to use different properties for DT and
> ACPI.
Which we would like to avoid.
Generally speaking, there are drivers (or upper-layer code) that will use
separate code paths for ACPI and DTs anyway (like the PCI root bridge
code) and in those cases having ACPI-specific properties or device data
in general is not really a problem.
However, for pieces of code that we'd like to use the unified properties
API going forward, we very much need the properties to be the same for
DTs and ACPI.
> I agree that there are too much ways to define GPIOs, but I'm afraid
> we will have to carry them over for the sake of consistency.
Well, I suppose so.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
