linux-kernel - Re: broonie-regulator/for-next boot bisection: v5.0-rc2-20-g61b67608c6b9 on meson-gxl-s905x-libretech-cc

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:   Tue, 15 Jan 2019 13:53:51 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     "kernelci.org bot" <bot@...nelci.org>,
        Neil Armstrong <narmstrong@...libre.com>
Cc:     Mark Brown <broonie@...nel.org>,
        Tomeu Vizoso <tomeu.vizoso@...labora.com>,
        guillaume.tucker@...labora.com,
        Kevin Hilman <khilman@...libre.com>,
        Haojian Zhuang <haojian.zhuang@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philipp Zabel <philipp.zabel@...il.com>,
        Paul Parsons <lost.distance@...oo.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: broonie-regulator/for-next boot bisection: v5.0-rc2-20-g61b67608c6b9
 on meson-gxl-s905x-libretech-cc

Thanks for this pretty impressive automated report!

Maybe it will be hard to ask a robot to test changes! :D

On Mon, Jan 14, 2019 at 11:04 PM kernelci.org bot <bot@...nelci.org> wrote:

>   Target:     meson-gxl-s905x-libretech-cc

I hope there is someone else with this board on CC since I don't
know how to ask the robot to test patches.

The log from the robot isn't super helpful as it does not have
earlyprintk enabled and boot hangs before it gets to that (!)
so no console messages.

So I suppose this is:
arch/arm64/boot/dts/amlogic/meson-gxl-s905x-libretech-cc.dts
a pure device tree plattform which was added by Neil, so I hope
he can test patches.

And that has only one GPIO regulator, this one:

        vcc_card: regulator-vcc-card {
                compatible = "regulator-gpio";

                regulator-name = "VCC_CARD";
                regulator-min-microvolt = <1800000>;
                regulator-max-microvolt = <3300000>;

                gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
                gpios-states = <0>;

                states = <3300000 0>,
                         <1800000 1>;

                regulator-settling-time-up-us = <200>;
                regulator-settling-time-down-us = <50000>;
        };

Meaning this is 3.3 V when that GPIO line is low, and 1.8V when that
line is high, correct?

That controls the VCC. This surely wouldn't block the boot process.
So my code must be crashing completely. OK I will look closer at it
and try to create a mock system of some sort.

Yours,
Linus Walleij