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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAGb2v65c2jFQCuAg_PhqJA+_m5Vi-cX=f8yHZ41P=_XnhBvKNQ@mail.gmail.com>
Date:   Mon, 5 Apr 2021 16:56:38 +0800
From:   Chen-Yu Tsai <wens@...nel.org>
To:     Tianling Shen <cnsztl@...il.com>
Cc:     Rob Herring <robh+dt@...nel.org>, Heiko Stuebner <heiko@...ech.de>,
        Johan Jonker <jbx6244@...il.com>,
        David Bauer <mail@...id-bauer.net>,
        Robin Murphy <robin.murphy@....com>,
        devicetree <devicetree@...r.kernel.org>,
        linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
        "open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rockchip: enabled LAN port on NanoPi R2S

On Mon, Apr 5, 2021 at 4:53 PM Tianling Shen <cnsztl@...il.com> wrote:
>
> Hi Chen-Yu,
>
> On 2021-04-05 16:14, Chen-Yu Tsai <wens@...nel.org> wrote:
> >
> > Hi,
> >
> > On Mon, Apr 5, 2021 at 3:46 PM Tianling Shen <cnsztl@...il.com> wrote:
> > >
> > > From: David Bauer <mail@...id-bauer.net>
> > >
> > > Enable the USB3 port on the FriendlyARM NanoPi R2S.
> > > This is required for the USB3 attached LAN port to work.
> > >
> > > Signed-off-by: David Bauer <mail@...id-bauer.net>
> > > Signed-off-by: Tianling Shen <cnsztl@...il.com>
> > > ---
> > >  .../boot/dts/rockchip/rk3328-nanopi-r2s.dts   | 23 +++++++++++++++++++
> > >  1 file changed, 23 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > index faf496d789cf..6ba9799a95c5 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3328-nanopi-r2s.dts
> > > @@ -37,6 +37,18 @@
> > >                 };
> > >         };
> > >
> > > +       vcc_rtl8153: vcc-rtl8153-regulator {
> > > +               compatible = "regulator-fixed";
> > > +               gpio = <&gpio2 RK_PC6 GPIO_ACTIVE_HIGH>;
> > > +               pinctrl-names = "default";
> > > +               pinctrl-0 = <&rtl8153_en_drv>;
> > > +               regulator-always-on;
> > > +               regulator-name = "vcc_rtl8153";
> > > +               regulator-min-microvolt = <5000000>;
> > > +               regulator-max-microvolt = <5000000>;
> >
> > This is just a simple switch, not an actual regulator.
> > It would make more sense to drop the voltage range and
> > instead have the implementation pass-through voltage
> > constraints from its parent.
>
> Thanks, I'll remove them in v2.
>
> >
> > > +               enable-active-high;
> > > +       };
> > > +
> > >         leds {
> > >                 compatible = "gpio-leds";
> > >                 pinctrl-0 = <&lan_led_pin>,  <&sys_led_pin>, <&wan_led_pin>;
> > > @@ -265,6 +277,12 @@
> > >                         };
> > >                 };
> > >         };
> > > +
> > > +       usb {
> > > +               rtl8153_en_drv: rtl8153-en-drv {
> > > +                       rockchip,pins = <2 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > > +               };
> > > +       };
> > >  };
> > >
> > >  &io_domains {
> > > @@ -364,6 +382,11 @@
> > >         dr_mode = "host";
> > >  };
> > >
> > > +&usbdrd3 {
> > > +       dr_mode = "host";
> > > +       status = "okay";
> >
> > Please also add a device node for the actual Ethernet controller, and
> > set up an aliases node for it, so that the bootloader has some place
> > to fill in a MAC address.
>
> But there's no valid (unique) MAC address for both this or on-board ethernet...
> They're non-existent in design.

Correct. And thanks for confirming that it's not just me and Robin that
got boards without the MAC address EEPROM...

If the user sets some MAC address in the bootloader environment by hand,
the bootloader could still potentially pass that MAC address to Linux
through the device tree. Whether the board has a valid address or not
is beside the point.


ChenYu


> Thanks,
> Tianling.
>
> >
> >
> > ChenYu
> >
> > > +};
> > > +
> > >  &usb_host0_ehci {
> > >         status = "okay";
> > >  };
> > > --
> > > 2.17.1
> > >
> > >
> > > _______________________________________________
> > > linux-arm-kernel mailing list
> > > linux-arm-kernel@...ts.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ