Re: [PATCH v3 05/15] gpio / ACPI: Add support for _DSD device properties

[Rafael J. Wysocki]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/