| 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
| ||
|
Date: Tue, 5 Jul 2016 20:33:53 +0200
From: Uwe Kleine-König
<u.kleine-koenig@...gutronix.de>
To: Andreas Färber <afaerber@...e.de>
Cc: Fabio Estevam <festevam@...il.com>,
Mark Rutland <mark.rutland@....com>,
devicetree <devicetree@...r.kernel.org>,
Russell King <linux@...linux.org.uk>,
LKML <linux-kernel@...r.kernel.org>,
Ettore Chimenti <ettore.chimenti@...o.org>,
Rob Herring <robh+dt@...nel.org>,
Sascha Hauer <kernel@...gutronix.de>,
Fabio Estevam <fabio.estevam@....com>,
Shawn Guo <shawnguo@...nel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/3] ARM: dts: imx6sx: Add UDOO Neo support
On Tue, Jul 05, 2016 at 03:55:23PM +0200, Andreas Färber wrote:
> Hi Fabio,
>
> Am 05.07.2016 um 14:04 schrieb Fabio Estevam:
> > On Tue, Jul 5, 2016 at 1:04 AM, Andreas Färber <afaerber@...e.de> wrote:
> >
> >> +/dts-v1/;
> >> +
> >> +#include "imx6sx-udoo-neo.dtsi"
> >> +
> >> +/ {
> >> + model = "UDOO Neo Basic";
> >
> > This should be something like:
> >
> > model = "Udoo i.MX6 SoloX UDOO Neo Basic";
>
> Why should anyone use such a weird concatenation of names? If you wanted
> "UDOO Neo Basic (based on i.MX 6SoloX)" that would be more
> understandable, but there is no UDOO Neo Basic board with another SoC:
>
> http://www.udoo.org/udoo-neo/
>
> imx6dl-udoo.dts uses "Udoo i.MX6 Dual-lite Board" and
> imx6q-udoo.dts uses "Udoo i.MX6 Quad Board".
Ack, I'm OK with "UDOO Neo Basic" et al, too.
> > [ discussion about what to use for compatible ]
> However, "udoo,neo-basic", "udoo,neo", "fsl,imx6sx" should be sufficient
> since unlike the Quad/Dual situation there is no SoC variation here. Or
> "seco,udoo-neo"? "udoo,udoo-neo" looks duplicate.
I'd use
"udoo,neo-basic", "fsl,imx6sx";
> >> +&fec1 {
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&pinctrl_enet1>;
> >> + phy-mode = "rmii";
> >> + phy-reset-gpios = <&gpio5 4 GPIO_ACTIVE_HIGH>;
> >
> > Shouldn't this be GPIO_ACTIVE_LOW instead?
>
> Hm, network worked okay for me like this, how do we verify?
>
> Schematics are here: http://www.udoo.org/other-resources/
The phy's RST# pin is connected to a signal that routes to ENET1_CRS /
C7. That corresponds to GPIO2_IO01.
Also that's what is used in "my" device tree that was created by a
colleague who probably took udoo's dts as reference.
Regarding the question how to verify that:
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ ifup eth0
eth0: 100Mbps full duplex link detected
T DHCP client bound to address 192.168.24.110
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ ping 192.168.23.4
host 192.168.23.4 is alive
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ gpio_direction_output 33 0
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ ping 192.168.23.4
eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
T eth0: transmission timeout
ping failed: Connection timed out
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ gpio_direction_output 33 1
barebox@...escale i.MX6 SoloX UDOO NEO Board:/ ping 192.168.23.4
host 192.168.23.4 is alive
So I'd say the right thing to do is:
phy-reset-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
And as the fec driver ignores the flag (for historic reasons), the only
other correct possibility is:
phy-reset-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>;
phy-reset-active-high;
which is wrong here though.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Powered by blists - more mailing lists