linux-kernel - Re: [PATCH 02/21] regulator: fixed: Convert to use GPIO descriptor only

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]

Message-ID: <CACRpkdYXx-nbSFEasioGHTzoOo2-nJ0whk-UVMgqYNNJuoT8bA@mail.gmail.com>
Date:   Thu, 19 Apr 2018 14:36:00 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        Alexander Shiyan <shc_work@...l.ru>,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Tony Lindgren <tony@...mide.com>,
        Mike Rapoport <mike@...pulab.co.il>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Philipp Zabel <philipp.zabel@...il.com>,
        Daniel Mack <zonque@...il.com>,
        Marc Zyngier <marc.zyngier@....com>,
        Geert Uytterhoeven <geert+renesas@...der.be>
Subject: Re: [PATCH 02/21] regulator: fixed: Convert to use GPIO descriptor only

On Mon, Feb 12, 2018 at 4:13 PM, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:

>> +static struct gpiod_lookup_table bcm43xx_vmmc_gpio_table = {
>> +     .dev_id = "reg-fixed-voltage.0",
>
> I'm not sure this will be always like this.
> We have DEVID_AUTO, which theoretically can be anything.
>
> Okay, it looks like we have only one static regulator for now for Intel
> MID. Though it's fragile if anything will change in the future (quite
> unlikely).

OK let's hope this doesn't blow up in our face :/
Then I have to think of something.

>> +     cfg.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, NULL,
>> gflags);
>
> Shouldn't we be a little bit more stricter here, i.e. require "enable"
> name?

It sadly won't work.

The reason is the way the regulator device tree bindings look,
specifying just:

Optional properties:
- gpio: gpio to use for enable control
- startup-delay-us: startup time in microseconds
- enable-active-high: Polarity of GPIO is Active high
If this property is missing, the default assumed is Active low.
- gpio-open-drain: GPIO is open drain type.
  If this property is missing then default assumption is false.
-vin-supply: Input supply name.

Not "enable-gpios" as we would write it today.

So it has to retrieve the first (and only) GPIO.

This is another of those historical artifacts, I have tried to
contain some of them, but I don't know if I can do much
about this one :/

Yours,
Linus Walleij