[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACRpkdYQthFgjwVzHyK3DeYUOdcYyWmdjDPG=Rf9B3VrJ12Rzg@mail.gmail.com>
Date: Wed, 17 Feb 2021 12:01:04 +0100
From: Linus Walleij <linus.walleij@...aro.org>
To: Heiner Kallweit <hkallweit1@...il.com>
Cc: DENG Qingfang <dqfext@...il.com>, Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
Florian Fainelli <f.fainelli@...il.com>,
Vladimir Oltean <olteanv@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
netdev <netdev@...r.kernel.org>,
Mauri Sandberg <sandberg@...lfence.com>
Subject: Re: [RFC net-next 1/2] net: dsa: add Realtek RTL8366S switch tag
On Wed, Feb 17, 2021 at 8:08 AM Heiner Kallweit <hkallweit1@...il.com> wrote:
> > +#define RTL8366S_HDR_LEN 4
> > +#define RTL8366S_ETHERTYPE 0x8899
>
> I found this protocol referenced as Realtek Remote Control Protocol (RRCP)
> and it seems to be used by few Realtek chips. Not sure whether this
> protocol is officially registered. If yes, then it should be added to
> the list of ethernet protocol id's in include/uapi/linux/if_ether.h.
> If not, then it may be better to define it using the usual naming
> scheme as ETH_P_RRCP in realtek-smi-core.h.
It's actually quite annoying, Realtek use type 0x8899 for all their
custom stuff, including RRCP and internal DSA tagging inside
switches, which are two completely different use cases.
When I expose raw DSA frames to wireshark it identifies it
as "Realtek RRCP" and then naturally cannot decode the
frames since this is not RRCP but another protocol identified
by the same ethertype.
Inside DSA it works as we explicitly asks tells the kernel using the
tagging code in net/dsa/tag_rtl4_a.c that this is the DSA version
of ethertype 0x8899 and it then goes to dissect the actual
4 bytes tag.
There are at least four protocols out there using ethertype 0x8899.
Yours,
Linus Walleij
Powered by blists - more mailing lists