netdev - Re: [PATCH net] net: dsa: mt7530: don't change PVC_EG

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: <20230206204228.sa45cvco6bltidwq@skbuf>
Date:   Mon, 6 Feb 2023 22:42:28 +0200
From:   Vladimir Oltean <vladimir.oltean@....com>
To:     Arınç ÜNAL <arinc.unal@...nc9.com>
Cc:     netdev@...r.kernel.org, "David S. Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org,
        Frank Wunderlich <frank-w@...lic-files.de>,
        erkin.bozoglu@...ont.com, richard@...terhints.com
Subject: Re: [PATCH net] net: dsa: mt7530: don't change PVC_EG_TAG when CPU
 port becomes VLAN-aware

On Mon, Feb 06, 2023 at 11:35:50PM +0300, Arınç ÜNAL wrote:
> On 06/02/2023 23:33, Vladimir Oltean wrote:
> > On Mon, Feb 06, 2023 at 10:41:47PM +0300, Arınç ÜNAL wrote:
> > > One last thing. Specific to MT7530 switch in MT7621 SoC, if port@5 is the
> > > only CPU port defined on the devicetree, frames sent from DSA master appears
> > > malformed on the user port. Packet capture on computer connected to the user
> > > port is attached.
> > > 
> > > The ARP frames on the pcapng file are received on the DSA master, I captured
> > > them with tcpdump, and put it in the attachments. Then I start pinging from
> > > the DSA master and the malformed frames appear on the pcapng file.
> > > 
> > > It'd be great if you could take a look this final issue.
> > 
> > What phy-mode does port@5 use when it doesn't work? What about the DSA master?
> 
> It's rgmii on port@5 and gmac1.

What kind of RGMII? Plain "rgmii" on both ends, with no internal delays?
With RGMII, somebody must add a skew to the clock signal relative to the
data signals, so that setup/hold times at the other end are not violated.
Either the transmitter or the receiver can add RGMII delays in each
direction of communication, but someone must do it, and no more than one
entity should do it.

So my question would be: could you retry after replacing phy-mode = "rgmii"
with phy-mode = "rgmii-id" on port@5? And if that doesn't change anything
(unlikely but possible), also try "rgmii-txid" and "rgmii-rxid" in port@5?
Don't change the phy-mode on gmac1.