lkml.org 
[lkml]   [2019]   [Apr]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 net-next 18/24] net: dsa: sja1105: Add support for traffic through standalone ports
On Sun, 14 Apr 2019 at 19:18, Andrew Lunn <andrew@lunn.ch> wrote:
>
> > > > > > + return dsa_8021q_xmit(skb, netdev, ETH_P_EDSA,
> > > > > > + ((pcp << VLAN_PRIO_SHIFT) | tx_vid));
> > > > >
> > > > > Please don't reuse ETH_P_EDSA. Define an ETH_P_SJA1105.
> > > > >
> >
> > I'm receiving contradictory advice on this. Why should I define a new
> > ethertype, and if I do, what scope should the definition have (local
> > to the driver and the tagger, local to DSA, UAPI)?
>
> ETH_P_EDSA has a well defined meaning. It is a true global EtherType,
> and means a Marvell EtherType DSA header follows.
>
> You are polluting this meaning of ETH_P_EDSA. Would you put ETH_P_IP
> or ETH_P_8021AD here?
>
> Andrew

You are putting an equality sign here between things that are not quite equal.
The MEDSA EtherType is used for the same purpose as what I'm using it for.
The only situation when I can receive ETH_P_EDSA frames is if somebody
designed a system with a cascaded SJA1105 and a MV88E6xx. I think
that's unlikely but I might be wrong.
Don't get me wrong, I could use literally any EtherType and that's
exactly why I'm reluctant to define a new one.
The only thing is that if I pick an EtherType smaller than 1500
(LLC/SNAP) like ETH_P_XDSA (or even zero works), then I get the
hardware incrementing the n_sizeerr counter for each received tagged
frame (it doesn't drop it, though).

-Vladimir

\
 
 \ /
  Last update: 2019-04-14 20:54    [W:0.085 / U:81.564 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site