| 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
| ||
|
Message-ID: <CACRpkdbZwfG2E8egObGkgTu2uL8auS5z2yzb0OH-UdAsnbrzHg@mail.gmail.com>
Date: Tue, 15 Aug 2023 00:21:19 +0200
From: Linus Walleij <linus.walleij@...aro.org>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Andrew Lunn <andrew@...n.ch>, Vladimir Oltean <olteanv@...il.com>,
Heiner Kallweit <hkallweit1@...il.com>, Florian Fainelli <f.fainelli@...il.com>,
"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] net: dsa: mark parsed interface mode for legacy
switch drivers
On Mon, Aug 14, 2023 at 6:27 PM Russell King (Oracle)
<linux@...linux.org.uk> wrote:
> > > ethernet@...00000 {
> > > ...
> > > ethernet-port@0 {
> > > phy-mode = "rgmii";
> > > fixed-link {
> > > speed = <1000>;
> > > full-duplex;
> > > pause;
> > > };
> > > };
> > >
> > > So that also uses "rgmii".
> > >
> > > I'm tempted not to allow the others as the driver doesn't make any
> > > adjustments, and we only apparently have the one user.
> >
> > RGMII on both ends is unlikely to work, so probably one is
> > wrong. Probably the switch has strapping to set it to rgmii-id, but we
> > don't actually know that. And i guess we have no ability to find out
> > the truth?
>
> "rgmii" on both ends _can_ work - from our own documentation:
>
> * PHY_INTERFACE_MODE_RGMII: the PHY is not responsible for inserting any
> internal delay by itself, it assumes that either the Ethernet MAC (if capable)
> or the PCB traces insert the correct 1.5-2ns delay
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> So, if the board is correctly laid out to include this delay, then RGMII
> on both ends can work.
>
> Next, we have no ability to find anything out - we have no hardware.
> LinusW does, but I have no idea whether Linus can read the state of the
> pin strapping. I can see from the RTL8366 info I found that there is
> a register that the delay settings can be read from, but this is not
> the RTL8366, it's RTL8366RB, which Linus already pointed out is
> revision B and is different. So, I would defer to Linus for anything on
> this, and without input from Linus, all we have to go on is what we
> have in the kernel sources.
I looked at the delays a bit, on the Gemini I think it is set up
from the pin control system, for example we have this in
arch/arm/boot/dts/gemini/gemini-sl93512r.dts:
pinctrl-gmii {
mux {
function = "gmii";
groups =
"gmii_gmac0_grp", "gmii_gmac1_grp";
};
/* Control pad skew comes from
sl_switch.c in the vendor code */
conf0 {
pins = "P10 GMAC1 TXC";
skew-delay = <5>;
};
conf1 {
pins = "V11 GMAC1 TXEN";
skew-delay = <7>;
};
conf2 {
pins = "T11 GMAC1 RXC";
skew-delay = <8>;
};
conf3 {
pins = "U11 GMAC1 RXDV";
skew-delay = <7>;
};
conf4 {
pins = "V7 GMAC0 TXC";
skew-delay = <10>;
};
conf5 {
pins = "P8 GMAC0 TXEN";
skew-delay = <7>; /* 5
at another place? */
};
conf6 {
pins = "T8 GMAC0 RXC";
skew-delay = <15>;
};
conf7 {
pins = "R8 GMAC0 RXDV";
skew-delay = <0>;
};
conf8 {
/* The data lines all
have default skew */
pins = "U8 GMAC0
RXD0", "V8 GMAC0 RXD1",
"P9 GMAC0
RXD2", "R9 GMAC0 RXD3",
"R11 GMAC1
RXD0", "P11 GMAC1 RXD1",
"V12 GMAC1
RXD2", "U12 GMAC1 RXD3",
"R10 GMAC1
TXD0", "T10 GMAC1 TXD1",
"U10 GMAC1
TXD2", "V10 GMAC1 TXD3";
skew-delay = <7>;
};
/* Appears in sl351x_gmac.c in
the vendor code */
conf9 {
pins = "U7 GMAC0
TXD0", "T7 GMAC0 TXD1",
"R7 GMAC0
TXD2", "P7 GMAC0 TXD3";
skew-delay = <5>;
};
};
};
For the DIR-685 this is set to the default value of 7 for all skews.
I haven't found any registers dealing with delays in RTL8366RB.
I might need to look closer (vendor mess...)
I think the PCB can have been engineered to match this since clearly
other PCBs contain elaborate values per line. Here is a picture
of the DIR-685 PCB:
https://www.redeszone.net/app/uploads-redeszone.net/d-link_dir-685_analisis_15-1024x755.jpg
the swirly lines to the right are toward the memory indicating that
the engineer is consciously designing delays on this board.
Yours,
Linus Walleij
Powered by blists - more mailing lists