linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Juergen Borleis <jbe@pengutronix.de>
To: kernel@pengutronix.de
Cc: Andrew Lunn <andrew@lunn.ch>,
	f.fainelli@gmail.com, vivien.didelot@savoirfairelinux.com,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	davem@davemloft.net
Subject: Re: [PATCH v2 1/4] net: dsa: add support for the SMSC-LAN9303 tagging format
Date: Mon, 10 Apr 2017 09:18:02 +0200	[thread overview]
Message-ID: <201704100918.03272.jbe@pengutronix.de> (raw)
In-Reply-To: <20170407130610.GD17290@lunn.ch>

Hi Andrew,

On Friday 07 April 2017 15:06:10 Andrew Lunn wrote:
> On Fri, Apr 07, 2017 at 10:14:59AM +0200, Juergen Borleis wrote:
> > To define the outgoing port and to discover the incoming port a regular
> > VLAN tag is used by the LAN9303. But its VID meaning is 'special'.
> >
> > This tag handler/filter depends on some hardware features which must be
> > enabled in the device to provide and make use of this special VLAN tag
> > to control the destination and the source of an ethernet packet.
> >
> > +
> > +/* To define the outgoing port and to discover the incoming port a
> > regular + * VLAN tag is used by the LAN9303. But its VID meaning is
> > 'special': + *
> > + *       Dest MAC       Src MAC        TAG    Type
> > + * ...| 1 2 3 4 5 6 | 1 2 3 4 5 6 | 1 2 3 4 | 1 2 |...
> > + *                                |<------->|
> > + * TAG:
> > + *    |<------------->|
> > + *    |  1  2 | 3  4  |
> > + *      TPID    VID
> > + *     0x8100
> > + *
> > + * VID bit 3 indicates a request for an ALR lookup.
>
> Maybe on the transmit path, you should look into the packet and see if
> there is already a VLAN header, and if bit 3 is set, drop the
> packet. Somebody could configure the stack from userspace to produce
> such packets to direct them out specific ports, which is not what you
> want. Worse still, this could be packets you are getting from
> somewhere else, e.g. a L2 VPN.

Hmm. In the transmit path the driver adds four bytes of explicit data after 
the two MACs to define the outgoing port. And the hardware uses the first 
TAG after the two MACs to forward the packet to a specific port. How should 
a userspace app manipulate this behaviour?
And if the packet to sent is already VLAN tagged, the driver still adds an 
additional TAG to define the outgoing port and the port itself removes this 
additional TAG when transmitting while the intended VLAN tag still remains. 
So I think an already existing VLAN tag doesn't interfere with the special 
port defining TAG. Or do I miss something?

Juergen

-- 
Pengutronix e.K.                             | Juergen Borleis             |
Industrial Linux Solutions                   | http://www.pengutronix.de/  |

  reply	other threads:[~2017-04-10  7:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-07  8:14 [PATCHv2] net: dsa: add SMSC/Microchip LAN9303 three port ethernet switch driver Juergen Borleis
2017-04-07  8:14 ` [PATCH v2 1/4] net: dsa: add support for the SMSC-LAN9303 tagging format Juergen Borleis
2017-04-07 13:06   ` Andrew Lunn
2017-04-10  7:18     ` Juergen Borleis [this message]
2017-04-10 13:15       ` Andrew Lunn
2017-04-07  8:15 ` [PATCH v2 2/4] net: dsa: add new DSA switch driver for the SMSC-LAN9303 Juergen Borleis
2017-04-07 13:35   ` David Miller
2017-04-07 14:29   ` Andrew Lunn
2017-04-10  7:44     ` Juergen Borleis
2017-04-10 13:25       ` Andrew Lunn
2017-04-07  8:15 ` [PATCH v2 3/4] net: dsa: LAN9303: add I2C managed mode support Juergen Borleis
2017-04-07 13:40   ` Andrew Lunn
2017-04-10  7:58     ` Juergen Borleis
2017-04-07  8:15 ` [PATCH v2 4/4] net: dsa: LAN9303: add MDIO " Juergen Borleis
2017-04-07 14:19   ` Andrew Lunn
2017-04-07 14:27     ` David Miller
2017-04-07 14:54   ` Andrew Lunn
2017-04-07 15:05   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201704100918.03272.jbe@pengutronix.de \
    --to=jbe@pengutronix.de \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=vivien.didelot@savoirfairelinux.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).