netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Lukasz Majewski <lukma@denx.de>
Cc: "David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	Madalin Bucur <madalin.bucur@oss.nxp.com>,
	Nicolas Ferre <nicolas.ferre@microchip.com>,
	Joakim Zhang <qiangqing.zhang@nxp.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Vladimir Oltean <olteanv@gmail.com>,
	netdev@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
	Mark Einon <mark.einon@gmail.com>,
	NXP Linux Team <linux-imx@nxp.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/3] net: Provide switchdev driver for NXP's More Than IP L2 switch
Date: Thu, 24 Jun 2021 18:11:40 +0200	[thread overview]
Message-ID: <YNSuvJsD0HSSshOJ@lunn.ch> (raw)
In-Reply-To: <20210624163542.5b6d87ee@ktm>

On Thu, Jun 24, 2021 at 04:35:42PM +0200, Lukasz Majewski wrote:
> Hi Andrew,
> 
> > > I'm not sure if the imx28 switch is similar to one from TI (cpsw-3g)
> > > - it looks to me that the bypass mode for both seems to be very
> > > different. For example, on NXP when switch is disabled we need to
> > > handle two DMA[01]. When it is enabled, only one is used. The
> > > approach with two DMAs is best handled with FEC driver
> > > instantiation.  
> > 
> > I don't know if it applies to the FEC, but switches often have
> > registers which control which egress port an ingress port can send
> > packets to. So by default, you allow CPU to port0, CPU to port1, but
> > block between port0 to port1. This would give you two independent
> > interface, the switch enabled, and using one DMA. When the bridge is
> > configured, you simply allow port0 and send/receive packets to/from
> > port1. No change to the DMA setup, etc.
> 
> Please correct me if I misunderstood this concept - but it seems like
> you refer to the use case where the switch is enabled, and by changing
> it's "allowed internal port's" mapping it decides if frames are passed
> between engress ports (port1 and port2).

Correct.


> 	----------
> DMA0 ->	|P0    P1| -> ENET-MAC (PHY control) -> eth0 (lan1)
> 	|L2 SW	 |
> 	|      P2| -> ENET-MAC (PHY control) -> eth1 (lan2)
> 	----------
> 
> DMA1 (not used)
> 
> We can use this approach when we keep always enabled L2 switch.
> 
> However now in FEC we use the "bypass" mode, where:
> DMA0 -> ENET-MAC (FEC instance driver 1) -> eth0
> DMA1 -> ENET-MAC (FEC instance driver 2) -> eth1
> 
> And the "bypass" mode is the default one.

Which is not a problem, when you refactor the FEC into a library and a
driver, plus add a new switch driver. When the FEC loads, it uses
bypass mode, the switch disabled. When the new switch driver loads, it
always enables the switch, but disables communication between the two
ports until they both join the same bridge.

But i doubt we are actually getting anywhere. You say you don't have
time to write a new driver. I'm not convinced you can hack the FEC
like you are suggesting and not end up in the mess the cpsw had,
before they wrote a new driver.

       Andrew

  reply	other threads:[~2021-06-24 16:11 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 14:41 [RFC 0/3] net: imx: Provide support for L2 switch as switchdev accelerator Lukasz Majewski
2021-06-22 14:41 ` [RFC 1/3] ARM: dts: imx28: Add description for L2 switch on XEA board Lukasz Majewski
2021-06-22 14:45   ` Andrew Lunn
2021-06-22 20:51     ` Lukasz Majewski
2021-06-23 13:17       ` Andrew Lunn
2021-06-23 15:26         ` Lukasz Majewski
2021-06-24  0:36           ` Florian Fainelli
2021-06-24  2:19             ` Joakim Zhang
2021-06-24 11:21               ` Lukasz Majewski
2021-06-25  8:28                 ` Joakim Zhang
2021-06-25 10:18                   ` Lukasz Majewski
2021-06-24 11:03             ` Lukasz Majewski
2021-06-22 14:41 ` [RFC 2/3] net: Provide switchdev driver for NXP's More Than IP L2 switch Lukasz Majewski
2021-06-22 15:03   ` Andrew Lunn
2021-06-23 11:37     ` Lukasz Majewski
2021-06-23 20:01       ` Andrew Lunn
2021-06-24 10:53         ` Lukasz Majewski
2021-06-24 13:34           ` Andrew Lunn
2021-06-24 14:35             ` Lukasz Majewski
2021-06-24 16:11               ` Andrew Lunn [this message]
2021-06-25  9:59                 ` Lukasz Majewski
2021-06-25 14:40                   ` Andrew Lunn
2021-06-28 12:05                     ` Lukasz Majewski
2021-06-28 12:48                       ` Vladimir Oltean
2021-06-28 14:13                         ` Lukasz Majewski
2021-06-28 14:23                           ` Vladimir Oltean
2021-06-29  8:09                             ` Lukasz Majewski
2021-06-29  9:30                               ` Vladimir Oltean
2021-06-29 12:01                                 ` Lukasz Majewski
2021-06-28 13:23                       ` Andrew Lunn
2021-06-28 14:14                         ` Lukasz Majewski
2021-06-22 14:41 ` [RFC 3/3] net: imx: Adjust fec_main.c to provide support for " Lukasz Majewski
2021-06-22 15:10   ` Andrew Lunn
2021-06-23  7:48     ` Lukasz Majewski
2021-06-25 22:04 ` [RFC 0/3] net: imx: Provide support for L2 switch as switchdev accelerator Vladimir Oltean
2021-06-28  9:41   ` Lukasz Majewski

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=YNSuvJsD0HSSshOJ@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=arnd@arndb.de \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-imx@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukma@denx.de \
    --cc=madalin.bucur@oss.nxp.com \
    --cc=mark.einon@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.ferre@microchip.com \
    --cc=olteanv@gmail.com \
    --cc=qiangqing.zhang@nxp.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).