linux-kernel - Re: [PATCH v7] 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]

Date:   Sat, 29 Sep 2018 19:38:12 +0200
From:   Linus Walleij <linus.walleij@...aro.org>
To:     John Stultz <john.stultz@...aro.org>
Cc:     Anders Roxell <anders.roxell@...aro.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Janusz Krzysztofik <jmkrzyszt@...il.com>,
        Alexander Shiyan <shc_work@...l.ru>,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        Aaro Koskinen <aaro.koskinen@....fi>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>,
        Robert Jarzmik <robert.jarzmik@...e.fr>,
        Philipp Zabel <philipp.zabel@...il.com>,
        Daniel Mack <zonque@...il.com>,
        Marc Zyngier <marc.zyngier@....com>,
        jacopo <jacopo@...ndi.org>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Russell King <rmk+kernel@...linux.org.uk>,
        Tom Gall <tom.gall@...aro.org>
Subject: Re: [PATCH v7] regulator: fixed: Convert to use GPIO descriptor only

On Sat, Sep 29, 2018 at 1:32 AM John Stultz <john.stultz@...aro.org> wrote:

>   Anders recently noted a regression in -next when running HiKey,
> where USB fails to function.  I took a look and could reproduce this
> as well, and after some unsuccessful muddling about in the usb
> changes, I bisected it down to your commit here (specifically
> efdfeb079cc3 in -next).
>
> I'm not sure exactly why this would cause trouble, but I suspect it
> has something to do w/ the cable-detect OTG to host-hub switch on the
> HiKey.
>
> Anyway, I just wanted to raise this with you so it can get sorted out
> before that patch hits mainline.

OK how typical, let's see if we can figure it out. I looked at it but
I can't see what it is right off.

I guess it is this from
arch/arm64/boot/dts/hisilicon/hi6220-hikey.dts:

        reg_5v_hub: regulator@2 {
                compatible = "regulator-fixed";
                regulator-name = "5V_HUB";
                regulator-min-microvolt = <5000000>;
                regulator-max-microvolt = <5000000>;
                regulator-boot-on;
                gpio = <&gpio0 7 0>;
                regulator-always-on;
                vin-supply = <&reg_sys_5v>;
        };

It's a regulator with one GPIO.

It used to be fetched here:

+       cfg.ena_gpiod = devm_gpiod_get_optional(&pdev->dev, NULL, gflags);
+       if (IS_ERR(cfg.ena_gpiod))
+               return PTR_ERR(cfg.ena_gpiod);

So first would be to put in a print like this:

if (IS_ERR(cfg.ena_gpiod)) {
    dev_info(&pdev->dev, "error fetching enable GPIO for %s, %d\n",
dev_name(&pdev->dev), PTR_ERR(cfg.ena_gpiod));
    return PTR_ERR(cfg.ena_gpiod);
}
if (!cfg.ena_gpiod)
    dev_info(&pdev->dev, "no enable GPIO for %s\n", dev_name(&pdev->dev));
else
    dev_info(&pdev->dev, "fetched valid enable GPIO for %s\n",
dev_name(&pdev->dev));

So we make sure we get the enable GPIO handle.

Else we need to troubleshoot that.
Look if -ENOENT or -EPROBE_DEFER gets returned for example.

If those works we need to check the flags. Since this GPIO is specified
with gpio = <&gpio0 7 0>; it would nominally mean it is active high.

But there is special code in drivers/gpio/gpiolib-of.c to deal with
regulators, since those lines are by default active low and ignore
the flags in the second cell from the device tree.
In of_gpio_flags_quirks(), we force the GPIO to be active low
unless "enable-active-high" is set. So we need to look
in /sys/kernel/debug/gpio or just lsgpio to see if the active edge
is the same before/after the patch.

Sadly I don't have this board myself!

Yours,
Linus Walleij