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: <CACRpkdY5ipcZqujGXJN9hcNYA+3WvknaQH0syYDb3YrrrgkgCg@mail.gmail.com>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ