lkml.org 
[lkml]   [2018]   [Mar]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH net-next 5/8] net: mscc: Add initial Ocelot switch support
On 30/03/2018 at 15:54:22 +0200, Andrew Lunn wrote:
> > > All of this sounds like it should be moved into the br_join/leave, this
> > > does not appear to be the right place to do that.
> > >
> >
> > No, I've triple checked because this is a comment that both Andrew and
> > you had. Once a port is added to the PGID MASK, it will start forwarding
> > frames so we really want that to happen only when the port is in
> > BR_STATE_FORWARDING state. Else, we may forward frames between the
> > addition of the port to the bridge and setting the port to the
> > BR_STATE_BLOCKING state.
>
> Hi Alexandre
>
> Interesting observation. I took a look at some of the other join
> implementations. mv88e6xxx does the join immediately. mt7539 does it
> immediately, if the port is enabled. lan9303 does it immediately.
> qca8k does it immediately. b53 does it immediately.
>

I had a look at b53, my impression was that b53_br_join() adds the port
to the bridge but b53_br_set_stp_state() actually enables forwarding. So
as long as the default on the port is PORT_CTRL_DIS_STATE, the port will
not be forwarding frames. And this is the case because b53_enable_port()
does put 0 in B53_PORT_CTRL.

The fact is that ocelot doesn't have separate controls. The port is
either forwarding or not. If it is not forwarding, then there is nothing
to tell the HW to do.


--
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

\
 
 \ /
  Last update: 2018-03-30 16:17    [W:0.115 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site