linux-kernel - Re: [PATCH v3 05/15] gpio / ACPI: Add support for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 05 Oct 2014 23:20:07 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	Alexandre Courbot <gnurou@...il.com>
Cc:	Arnd Bergmann <arnd@...db.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Bryan Wu <cooloney@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	Grant Likely <grant.likely@...aro.org>,
	Aaron Lu <aaron.lu@...el.com>,
	Darren Hart <dvhart@...ux.intel.com>
Subject: Re: [PATCH v3 05/15] gpio / ACPI: Add support for _DSD device properties

On Sunday, October 05, 2014 07:36:04 PM Alexandre Courbot wrote:
> On Wed, Oct 1, 2014 at 5:03 PM, Arnd Bergmann <arnd@...db.de> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/