Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
On October 14, 2017 2:59:22 PM PDT, Linus Walleij wrote: >On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli > wrote: > >> The most deployed switch device drivers have been converted to DSA >> already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in >> tree, and now we are getting new submissions from Michrochip to >support >> their pretty large KSZ series. Converting from swconfig to DSA is >> actually quite simple, but like anything requires time and testing, >and >> access to hardware and ideally datasheet. > >Hm, I have a Realtek RB8366RB in this router on my desk. > >I guess that means I should just take the old switchdev-based >SMI-driver and convert it to DSA. > >I bet I can do that :D Yes, it really should not be too hard. The OpenWrt/LEDE driver had mostly the same semantics as what is needed for being a proper DSA driver. You should of course start simple: get basic switching working, then add statistics, VLAN, FDB, etc. OpenWrt/LEDE models switches as PHY device objects which would not work upstream so you should have the driver be probed as a MDIO/SPI/I2C (see b53 for example) and set up fixed-link properties between the CPU and the switch. > >Well, I will try. Because it's blocking me to work on the Gemini >ethernet driver. Well usually the boot loader may leave the switch in a good enough state that you can work on the CPU controller mostly independently from dealing with the switch. This is not universally true, and a properly working bootloader should actually quiesce/reset both blocks prior to OS control. Don't hesitate if you have questions. Cheers. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
On Sat, Oct 14, 2017 at 8:52 PM, Florian Fainelli wrote: > The most deployed switch device drivers have been converted to DSA > already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in > tree, and now we are getting new submissions from Michrochip to support > their pretty large KSZ series. Converting from swconfig to DSA is > actually quite simple, but like anything requires time and testing, and > access to hardware and ideally datasheet. Hm, I have a Realtek RB8366RB in this router on my desk. I guess that means I should just take the old switchdev-based SMI-driver and convert it to DSA. I bet I can do that :D Well, I will try. Because it's blocking me to work on the Gemini ethernet driver. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
Hi, On 10/14/2017 04:09 AM, Linus Walleij wrote: > Top posting and resending since net...@vger.kernel.org > is the right mail address for this. Mea culpa. > > Linus Walleij > > On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij > wrote: >> On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu >> wrote: >> >>> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs >>> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages >>> switch objects discovered on the fsl-mc bus. A description of the driver >>> can be found in the associated README file. >>> >>> The patchset consists of: >>> * A set of libraries containing APIs for configuring and controlling >>> Management Complex (MC) switch objects >>> * The DPAA2 Ethernet Switch driver >>> * Patch adding ethtool support >> >> So it appears that ethernet switches is a class of device that need their own >> subsystem in Linux, before this driver can move out of staging. FWIW, I think the biggest dependency on this driver is not a switch driver model because that exists but it's actually the specific bus (MC AFAICT) that it depends on. More on the Ethernet switch device model below. We do actually have a pretty good model for Ethernet switches now, in fact, we got several options: - Distributed Switching Architecture (DSA) should be used when the CPU/management Ethernet controller is a traditional Ethernet MAC that is either internally or externally attached to a switch. This usually comes with the Ethernet switch capable of providing per-packet metadata (tag) to indicate to the management interface why the packet is transmitted. For older/dumber switches, using no management tag, but separating with 802.1Q tags is definitively an option that brings in the same requirements for DSA. DSA does make use of switchdev to get notified from the networking stack when there is an opportunity to offload objects: VLAN, FDB, MDB, etc. DSA is both a device driver model and a switch device abstraction model. - switchdev should be used when the management interface is tightly coupled with the switching hardware, such that, per-packet information is obtained via DMA/PIO descriptors for instance. switchdev is not a device driver model so the switch driver is responsible for creating its own net_device instances and feeding the appropriate netdev_ops, ethtool_ops and switchdev_ops, this is what is being done here, and this is also perfectly fine. >> >> I ran into the problem in OpenWRT that has these out-of-tree patches for >> off-chip ethernet switches, conveniently placed under net/phy: >> https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy >> >> These are some 12 different ethernet switches. It is used in more or >> less every home router out there. The most deployed switch device drivers have been converted to DSA already: b53, qca8k (ar83xx in OpenWrt/LEDE) and mtk7530 are all in tree, and now we are getting new submissions from Michrochip to support their pretty large KSZ series. Converting from swconfig to DSA is actually quite simple, but like anything requires time and testing, and access to hardware and ideally datasheet. >> >> It's not really working to have all of this out-of-tree, there must have been >> discussions about the requirements for a proper ethernet switch subsystem. >> >> I'm not a good net developers, just a grumpy user having to deal with all >> of this out-of-tree code that's not helpful with changing interfaces like >> device tree and so on. >> >> Can you people who worked on this over the years pit in with your >> requirements for an ethernet switch subsystem so we can house these >> drivers in a proper way? >> >> What we need AFAICT: >> >> - Consensus on userspace ABI >> - Consensus on ethtool extenstions >> - Consensus on where in drivers/net this goes >> >> You can kick me for not knowing what I'm talking about and how complex the >> problem is now. Kicking you would not be fair, but you are about 3 years late ;) We had such discussions in 2014 after a failed attempt at submitting swconfig as a possible model. 3 years later we have 1 major switchdev driver: mlxsw and quite a few active DSA drivers. The paradigms that apply are: - normal Linux tools keep working: bridge, iproute2, ethtool - every user-visible port has a corresponding network device, in order to meet the first paradigm - for every other part of the switch that does not have a net_device representor, devlink can/should be used. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] MV88E6060 switch
On Thu, 12 Oct 2017 03:11:21 +0300 Sergey Ryazanov wrote: > > I assume the new board type should be added to the config file, > > for which this patch should be enabled? > > I do not think so. These two patches are just a quick hacks to fix > common underlying issues. > > The first patch completes the work of adding phy(s) without the > standard MDIO interface, so it should be merged to existing patches. > > The second patch fixes the issue, which was introduced by > 304-ixp4xx_eth_jumboframe.patch, which adds JumboFrames support. So we > either should completely remove jumboframe support patch. Or, if > someone really use jumboframe feature, then we should to rework this > patch to avoid memory issues when using a regular MTU. > > I can try to make normal (and formal) fixes in a couple of days. It > would be nice if you could test them when they will be ready. Thank you. Another question about wifi - there is no /etc/config/wireless file, and even if I create it and reboot the device, wifi is not working and there is no wlan0 interface. ath5k module is loaded. Regards, Nerijus ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
Top posting and resending since net...@vger.kernel.org is the right mail address for this. Mea culpa. Linus Walleij On Sat, Oct 14, 2017 at 11:35 AM, Linus Walleij wrote: > On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu > wrote: > >> This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs >> with DPAA2 (DataPath Acceleration Architecture v2). The driver manages >> switch objects discovered on the fsl-mc bus. A description of the driver >> can be found in the associated README file. >> >> The patchset consists of: >> * A set of libraries containing APIs for configuring and controlling >> Management Complex (MC) switch objects >> * The DPAA2 Ethernet Switch driver >> * Patch adding ethtool support > > So it appears that ethernet switches is a class of device that need their own > subsystem in Linux, before this driver can move out of staging. > > I ran into the problem in OpenWRT that has these out-of-tree patches for > off-chip ethernet switches, conveniently placed under net/phy: > https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy > > These are some 12 different ethernet switches. It is used in more or > less every home router out there. > > It's not really working to have all of this out-of-tree, there must have been > discussions about the requirements for a proper ethernet switch subsystem. > > I'm not a good net developers, just a grumpy user having to deal with all > of this out-of-tree code that's not helpful with changing interfaces like > device tree and so on. > > Can you people who worked on this over the years pit in with your > requirements for an ethernet switch subsystem so we can house these > drivers in a proper way? > > What we need AFAICT: > > - Consensus on userspace ABI > - Consensus on ethtool extenstions > - Consensus on where in drivers/net this goes > > You can kick me for not knowing what I'm talking about and how complex the > problem is now. > > Yours, > Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 0/6] staging: Introduce DPAA2 Ethernet Switch driver
On Thu, Oct 5, 2017 at 11:16 AM, Razvan Stefanescu wrote: > This patchset introduces the Ethernet Switch Driver for Freescale/NXP SoCs > with DPAA2 (DataPath Acceleration Architecture v2). The driver manages > switch objects discovered on the fsl-mc bus. A description of the driver > can be found in the associated README file. > > The patchset consists of: > * A set of libraries containing APIs for configuring and controlling > Management Complex (MC) switch objects > * The DPAA2 Ethernet Switch driver > * Patch adding ethtool support So it appears that ethernet switches is a class of device that need their own subsystem in Linux, before this driver can move out of staging. I ran into the problem in OpenWRT that has these out-of-tree patches for off-chip ethernet switches, conveniently placed under net/phy: https://github.com/openwrt/openwrt/tree/master/target/linux/generic/files/drivers/net/phy These are some 12 different ethernet switches. It is used in more or less every home router out there. It's not really working to have all of this out-of-tree, there must have been discussions about the requirements for a proper ethernet switch subsystem. I'm not a good net developers, just a grumpy user having to deal with all of this out-of-tree code that's not helpful with changing interfaces like device tree and so on. Can you people who worked on this over the years pit in with your requirements for an ethernet switch subsystem so we can house these drivers in a proper way? What we need AFAICT: - Consensus on userspace ABI - Consensus on ethtool extenstions - Consensus on where in drivers/net this goes You can kick me for not knowing what I'm talking about and how complex the problem is now. Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
