[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdb=16uLhsXhktLCwUByDAMv9Arg2zzCA+oJW2HBJ35-Bg@mail.gmail.com>
Date: Tue, 31 Oct 2023 20:02:29 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>, 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,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2] net: dsa: tag_rtl4_a: Bump min packet size
On Tue, Oct 31, 2023 at 5:34 PM Vladimir Oltean <olteanv@...il.com> wrote:
> Ok, so we don't have a confirmation of breakage with other conduit
> interface than the Gemini driver, either. So a problem there is still
> not off the table.
True!
> So on the gemini-dlink-dir-685.dts platform, you can also use &gmac1 as
> a plain Ethernet port, right?
As a port it exist on the SoC yes but it is not connected physically
to anything.
&gmac0 is connected to the switch, and the switch has all the PHYs.
(I don't know if I misunderstand the question...)
> If possible, could you set up dsa_loop (enable CONFIG_NET_DSA_LOOP, replace
> "eth0" in dsa_loop_pdata with the netdev name of &gmac1, replace DSA_TAG_PROTO_NONE
> in dsa_loop_get_protocol() with your tagging protocol) and put a tcpdump
> on the remote end of the gmac1 port, to see if the issue isn't, in fact,
> somewhere else, maybe gmac_start_xmit()?
If you by remote end mean the end of a physical cable there is
no way I can do that, as I have no PHY on gmac1.
But I have other Gemini platforms, so I will try to do it on one
of them! Let's see if I can do this thing....
Yours,
Linus Walleij
Powered by blists - more mailing lists