Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Andrew Lunn
> Out of curiosity: Are there fundamental reasons why ToR switches don't use > the DSA model, or is it more historical? Yes, there is a fundamental reason. https://www.netdevconf.org/2.1/session.html?lunn_didelot_fainelli DSA always has a host Ethernet interface connected to a port of the

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Andrew Lunn
> OK, so looks like DSA is actually what I need. I just didn't see a clear > implementation path for e.g. ACL functions. > Correct me if I'm wrong, to add support for ar8327 ACL or port rate control > I should expand struct dsa_switch_ops, add appropriate infrastructure in > netfilter/tc

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Egil Hjelmeland
On 09. nov. 2017 14:24, Andrew Lunn wrote: What should also be considered is who is pushing swithdev and DSA forward, and for what market. Pure switchdev drivers is mostly being pushed forward for Top or Rack switches. Big switches, 10G, 40G, 100G ports and lots of them. L3 routing, etc.

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Roman Yeryomin
On 2017-11-09 20:08, Florian Fainelli wrote: On 11/09/2017 09:24 AM, Andrew Lunn wrote: The registers writing code is where? switchdev driver? All I care about is that all the switch specific code should be in one place. The switch specific code is in the switch specific driver. Take a

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Roman Yeryomin
On 2017-11-09 19:24, Andrew Lunn wrote: The registers writing code is where? switchdev driver? All I care about is that all the switch specific code should be in one place. The switch specific code is in the switch specific driver. Take a look under drivers/net/dsa for the switches which are

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-10 Thread Linus Walleij
On Thu, Nov 9, 2017 at 7:08 PM, Florian Fainelli wrote: > if you are thinking about converting existing swconfig > drivers from OpenWrt/LEDE into DSA, please do it! The conversion is > reasonably simple even if the APIs do not exactly match. I can confirm this :) It's

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Florian Fainelli
On 11/09/2017 09:24 AM, Andrew Lunn wrote: >> The registers writing code is where? switchdev driver? >> All I care about is that all the switch specific code should be in one >> place. > > The switch specific code is in the switch specific driver. > > Take a look under drivers/net/dsa for the

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Andrew Lunn
> The registers writing code is where? switchdev driver? > All I care about is that all the switch specific code should be in one > place. The switch specific code is in the switch specific driver. Take a look under drivers/net/dsa for the switches which are currently supported by DSA.

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Roman Yeryomin
On 2017-11-09 17:38, Andrew Lunn wrote: >>Unless switchdev could be expanded to support other functions beyond >>VLAN, >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit >>this), etc. > >Switchdev allows offloading of TC. So port rate control would be >implemented via TC.

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Andrew Lunn
> >>Unless switchdev could be expanded to support other functions beyond > >>VLAN, > >>like port rate control, ACL, HW NAT (no switchdev L3 offload doesn't fit > >>this), etc. > > > >Switchdev allows offloading of TC. So port rate control would be > >implemented via TC. > > That's interesting.

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Roman Yeryomin
On 2017-11-09 15:24, Andrew Lunn wrote: Although it could be a good thing to bring this to mainline, I'm kind of pessimistic about supporting such switches in DSA/switchdev. IMO swconfig does a better job for now. I think the important point here is "... for now" ... as always, probably

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Andrew Lunn
> Although it could be a good thing to bring this to mainline, I'm kind of > pessimistic about supporting such switches in DSA/switchdev. IMO swconfig > does a better job for now. I think the important point here is "... for now" > Unless switchdev could be expanded to support other functions

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-09 Thread Roman Yeryomin
On 2017-11-06 01:19, Linus Walleij wrote: This adds a driver core for the Realtek SMI chips and a subdriver for the RTL8366RB. I just added this chip simply because it is all I can test. The code is a massaged variant of the code that has been sitting out-of-tree in OpenWRT for years in the

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-06 Thread Linus Walleij
On Mon, Nov 6, 2017 at 12:59 AM, Andrew Lunn wrote: > I'm wondering if this should be modelled as a normal MDIO bus? Put the > driver as drivers/net/mdio-realtek.c? I looked into it but couldn't find a good fit. The MDIO bus makes much more sense since more than one vendor is

Re: [PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-05 Thread Andrew Lunn
Hi Linus > +static int realtek_smi_read_reg(struct realtek_smi *smi, u32 addr, u32 *data) > +{ > + unsigned long flags; > + u8 lo = 0; > + u8 hi = 0; > + int ret; > + > + spin_lock_irqsave(>lock, flags); > + > + realtek_smi_start(smi); > + > + /* send READ command */ >

[PATCH 4/4] RFC: net: dsa: realtek-smi: Add Realtek SMI driver

2017-11-05 Thread Linus Walleij
This adds a driver core for the Realtek SMI chips and a subdriver for the RTL8366RB. I just added this chip simply because it is all I can test. The code is a massaged variant of the code that has been sitting out-of-tree in OpenWRT for years in the absence of a proper switch subsystem. I have