linux-kernel - Re: [PATCH v3 3/3] arm64: dts: meson: Add minimal support for Odroid-N2

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: <CAFBinCDzvroNfzhZHhDdvc+VR1eQNg5JMJ7F9=++hdWKcEXSOw@mail.gmail.com>
Date:   Tue, 21 May 2019 20:01:51 +0200
From:   Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To:     Neil Armstrong <narmstrong@...libre.com>
Cc:     khilman@...libre.com, linux-amlogic@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v3 3/3] arm64: dts: meson: Add minimal support for Odroid-N2

Hi Neil,

On Tue, May 21, 2019 at 5:20 PM Neil Armstrong <narmstrong@...libre.com> wrote:
[...]
> +       hub_5v: regulator-hub_5v {
> +               compatible = "regulator-fixed";
> +               regulator-name = "HUB_5V";
> +               regulator-min-microvolt = <5000000>;
> +               regulator-max-microvolt = <5000000>;
> +               vin-supply = <&vcc_5v>;
> +
> +               gpio = <&gpio GPIOH_5 GPIO_ACTIVE_HIGH>;
I missed this in the review of v1:
according to the schematics GPIOH_5 is routed to GL3523 (soldered down
USB hub) CHIP_EN signal.
The datasheet [0] mentions that this will "Disable whole chip and keep
hub in lowest power state (standby mode)"

do you know if this is a similar case as GPIOH_4 (USB hub reset line,
we configure this using a gpio-hog)?

[...]
> +&ext_mdio {
> +       external_phy: ethernet-phy@0 {
> +               /* Realtek RTL8211F (0x001cc916) */
> +               reg = <0>;
> +               max-speed = <1000>;
> +               eee-broken-1000t;
are we in the same situation that we have on the X96 Max where network
dies without eee-broken-1000t?

[...]
> +&usb2_phy0 {
> +       phy-supply = <&usb_pwr_en>;
is usb_pwr_en really the phy-supply or is it the vbus-supply of the
USB top control block (&usb node)?

if these three questions are answered then you can add my:
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@...glemail.com>


Regards
Martin


[0] https://datasheet.lcsc.com/szlcsc/GL3523-OV3S1_C157363.pdf