* [PATCH net-next 0/6] Microsemi Felix switch support @ 2019-06-21 15:38 Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 1/6] ocelot: Filter out ocelot SoC specific PCS config from common path Claudiu Manoil ` (5 more replies) 0 siblings, 6 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver This device is an ethernet switch core from Microsemi (VSC9959) integrated as PCIe endpoint into the LS1028a SoC. Though this switch core has some particularities (i.e. 6 ports, some register mapping differences), functionally this driver relies entirely on the Ocelot switch driver providing all the features, and is basically an instance of the Ocelot core driver. The first 3 patches are minor refactoring of the common Ocelot code (core driver). The rest provide the integration code of the switch as a PCIe device, the register mapping, corresponding ls1028a DT nodes (for switch ports link configuration). There are also few particularities described by individual patch messages. Claudiu Manoil (6): ocelot: Filter out ocelot SoC specific PCS config from common path ocelot: Refactor common ocelot probing code to ocelot_init ocelot: Factor out resource ioremap and regmap init common code arm64: dts: fsl: ls1028a: Add Felix switch port DT node dt-bindings: net: Add DT bindings for Microsemi Felix Switch net/mssc/ocelot: Add basic Felix switch driver .../devicetree/bindings/net/mscc-felix.txt | 77 +++ .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 58 ++- drivers/net/ethernet/mscc/Kconfig | 8 + drivers/net/ethernet/mscc/Makefile | 9 +- drivers/net/ethernet/mscc/felix_board.c | 392 +++++++++++++++ drivers/net/ethernet/mscc/felix_regs.c | 448 ++++++++++++++++++ drivers/net/ethernet/mscc/ocelot.c | 23 +- drivers/net/ethernet/mscc/ocelot.h | 13 +- drivers/net/ethernet/mscc/ocelot_board.c | 16 +- drivers/net/ethernet/mscc/ocelot_io.c | 14 +- drivers/net/ethernet/mscc/ocelot_regs.c | 21 + 11 files changed, 1041 insertions(+), 38 deletions(-) create mode 100644 Documentation/devicetree/bindings/net/mscc-felix.txt create mode 100644 drivers/net/ethernet/mscc/felix_board.c create mode 100644 drivers/net/ethernet/mscc/felix_regs.c -- 2.17.1 ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH net-next 1/6] ocelot: Filter out ocelot SoC specific PCS config from common path 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 2/6] ocelot: Refactor common ocelot probing code to ocelot_init Claudiu Manoil ` (4 subsequent siblings) 5 siblings, 0 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver The adjust_link routine should be generic enough to be (re)used by any SoC that integrates a switch core compatible with the Ocelot core switch driver. Currently all configurations are generic except for the PCS settings that are SoC specific. Move these out to the Ocelot SoC/board instance. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- drivers/net/ethernet/mscc/ocelot.c | 17 ++--------------- drivers/net/ethernet/mscc/ocelot.h | 2 ++ drivers/net/ethernet/mscc/ocelot_regs.c | 21 +++++++++++++++++++++ 3 files changed, 25 insertions(+), 15 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c index b71e4ecbe469..66cf57e6fd76 100644 --- a/drivers/net/ethernet/mscc/ocelot.c +++ b/drivers/net/ethernet/mscc/ocelot.c @@ -405,21 +405,8 @@ static void ocelot_port_adjust_link(struct net_device *dev) ocelot_port_writel(port, DEV_MAC_HDX_CFG_LATE_COL_POS(67), DEV_MAC_HDX_CFG); - /* Disable HDX fast control */ - ocelot_port_writel(port, DEV_PORT_MISC_HDX_FAST_DIS, DEV_PORT_MISC); - - /* SGMII only for now */ - ocelot_port_writel(port, PCS1G_MODE_CFG_SGMII_MODE_ENA, PCS1G_MODE_CFG); - ocelot_port_writel(port, PCS1G_SD_CFG_SD_SEL, PCS1G_SD_CFG); - - /* Enable PCS */ - ocelot_port_writel(port, PCS1G_CFG_PCS_ENA, PCS1G_CFG); - - /* No aneg on SGMII */ - ocelot_port_writel(port, 0, PCS1G_ANEG_CFG); - - /* No loopback */ - ocelot_port_writel(port, 0, PCS1G_LB_CFG); + if (ocelot->port_pcs_init) + ocelot->port_pcs_init(port); /* Set Max Length and maximum tags allowed */ ocelot_port_writel(port, VLAN_ETH_FRAME_LEN, DEV_MAC_MAXLEN_CFG); diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h index f7eeb4806897..e21a6fb22ef8 100644 --- a/drivers/net/ethernet/mscc/ocelot.h +++ b/drivers/net/ethernet/mscc/ocelot.h @@ -442,6 +442,8 @@ struct ocelot { u64 *stats; struct delayed_work stats_work; struct workqueue_struct *stats_queue; + + void (*port_pcs_init)(struct ocelot_port *port); }; struct ocelot_port { diff --git a/drivers/net/ethernet/mscc/ocelot_regs.c b/drivers/net/ethernet/mscc/ocelot_regs.c index 6c387f994ec5..000c43984858 100644 --- a/drivers/net/ethernet/mscc/ocelot_regs.c +++ b/drivers/net/ethernet/mscc/ocelot_regs.c @@ -412,6 +412,26 @@ static void ocelot_pll5_init(struct ocelot *ocelot) HSIO_PLL5G_CFG2_AMPC_SEL(0x10)); } +static void ocelot_port_pcs_init(struct ocelot_port *port) +{ + /* Disable HDX fast control */ + ocelot_port_writel(port, DEV_PORT_MISC_HDX_FAST_DIS, DEV_PORT_MISC); + + /* SGMII only for now */ + ocelot_port_writel(port, PCS1G_MODE_CFG_SGMII_MODE_ENA, + PCS1G_MODE_CFG); + ocelot_port_writel(port, PCS1G_SD_CFG_SD_SEL, PCS1G_SD_CFG); + + /* Enable PCS */ + ocelot_port_writel(port, PCS1G_CFG_PCS_ENA, PCS1G_CFG); + + /* No aneg on SGMII */ + ocelot_port_writel(port, 0, PCS1G_ANEG_CFG); + + /* No loopback */ + ocelot_port_writel(port, 0, PCS1G_LB_CFG); +} + int ocelot_chip_init(struct ocelot *ocelot) { int ret; @@ -420,6 +440,7 @@ int ocelot_chip_init(struct ocelot *ocelot) ocelot->stats_layout = ocelot_stats_layout; ocelot->num_stats = ARRAY_SIZE(ocelot_stats_layout); ocelot->shared_queue_sz = 224 * 1024; + ocelot->port_pcs_init = ocelot_port_pcs_init; ret = ocelot_regfields_init(ocelot, ocelot_regfields); if (ret) -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH net-next 2/6] ocelot: Refactor common ocelot probing code to ocelot_init 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 1/6] ocelot: Filter out ocelot SoC specific PCS config from common path Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 3/6] ocelot: Factor out resource ioremap and regmap init common code Claudiu Manoil ` (3 subsequent siblings) 5 siblings, 0 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver This is just common path code that belogs to ocelot_init, it has nothing to do with a specific SoC/board instance. Add allocation err check in the process. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- drivers/net/ethernet/mscc/ocelot.c | 6 ++++++ drivers/net/ethernet/mscc/ocelot_board.c | 4 ---- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot.c b/drivers/net/ethernet/mscc/ocelot.c index 66cf57e6fd76..f07c398f8b21 100644 --- a/drivers/net/ethernet/mscc/ocelot.c +++ b/drivers/net/ethernet/mscc/ocelot.c @@ -1674,6 +1674,11 @@ int ocelot_init(struct ocelot *ocelot) int i, cpu = ocelot->num_phys_ports; char queue_name[32]; + ocelot->ports = devm_kcalloc(ocelot->dev, ocelot->num_phys_ports, + sizeof(struct ocelot_port *), GFP_KERNEL); + if (!ocelot->ports) + return -ENOMEM; + ocelot->lags = devm_kcalloc(ocelot->dev, ocelot->num_phys_ports, sizeof(u32), GFP_KERNEL); if (!ocelot->lags) @@ -1692,6 +1697,7 @@ int ocelot_init(struct ocelot *ocelot) if (!ocelot->stats_queue) return -ENOMEM; + INIT_LIST_HEAD(&ocelot->multicast); ocelot_mact_init(ocelot); ocelot_vlan_init(ocelot); ocelot_ace_init(ocelot); diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c index 58bde1a9eacb..2a6ee4edb858 100644 --- a/drivers/net/ethernet/mscc/ocelot_board.c +++ b/drivers/net/ethernet/mscc/ocelot_board.c @@ -255,10 +255,6 @@ static int mscc_ocelot_probe(struct platform_device *pdev) ocelot->num_phys_ports = of_get_child_count(ports); - ocelot->ports = devm_kcalloc(&pdev->dev, ocelot->num_phys_ports, - sizeof(struct ocelot_port *), GFP_KERNEL); - - INIT_LIST_HEAD(&ocelot->multicast); ocelot_init(ocelot); for_each_available_child_of_node(ports, portnp) { -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH net-next 3/6] ocelot: Factor out resource ioremap and regmap init common code 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 1/6] ocelot: Filter out ocelot SoC specific PCS config from common path Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 2/6] ocelot: Refactor common ocelot probing code to ocelot_init Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node Claudiu Manoil ` (2 subsequent siblings) 5 siblings, 0 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver Let's make this ioremap and regmap init code common. It should not be platform dependent as it should be usable by PCI devices too. Use better names where necessary to avoid clashes. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- drivers/net/ethernet/mscc/ocelot.h | 4 +--- drivers/net/ethernet/mscc/ocelot_board.c | 12 ++++++++---- drivers/net/ethernet/mscc/ocelot_io.c | 14 +++++--------- 3 files changed, 14 insertions(+), 16 deletions(-) diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h index e21a6fb22ef8..4235d7294772 100644 --- a/drivers/net/ethernet/mscc/ocelot.h +++ b/drivers/net/ethernet/mscc/ocelot.h @@ -493,9 +493,7 @@ void ocelot_port_writel(struct ocelot_port *port, u32 val, u32 reg); int ocelot_regfields_init(struct ocelot *ocelot, const struct reg_field *const regfields); -struct regmap *ocelot_io_platform_init(struct ocelot *ocelot, - struct platform_device *pdev, - const char *name); +struct regmap *ocelot_io_init(struct ocelot *ocelot, struct resource *res); #define ocelot_field_write(ocelot, reg, val) regmap_field_write((ocelot)->regfields[(reg)], (val)) #define ocelot_field_read(ocelot, reg, val) regmap_field_read((ocelot)->regfields[(reg)], (val)) diff --git a/drivers/net/ethernet/mscc/ocelot_board.c b/drivers/net/ethernet/mscc/ocelot_board.c index 2a6ee4edb858..489177058d9e 100644 --- a/drivers/net/ethernet/mscc/ocelot_board.c +++ b/drivers/net/ethernet/mscc/ocelot_board.c @@ -182,7 +182,7 @@ static int mscc_ocelot_probe(struct platform_device *pdev) struct { enum ocelot_target id; char *name; - } res[] = { + } io_target[] = { { SYS, "sys" }, { REW, "rew" }, { QSYS, "qsys" }, @@ -201,14 +201,18 @@ static int mscc_ocelot_probe(struct platform_device *pdev) platform_set_drvdata(pdev, ocelot); ocelot->dev = &pdev->dev; - for (i = 0; i < ARRAY_SIZE(res); i++) { + for (i = 0; i < ARRAY_SIZE(io_target); i++) { struct regmap *target; + struct resource *res; + + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, + io_target[i].name); - target = ocelot_io_platform_init(ocelot, pdev, res[i].name); + target = ocelot_io_init(ocelot, res); if (IS_ERR(target)) return PTR_ERR(target); - ocelot->targets[res[i].id] = target; + ocelot->targets[io_target[i].id] = target; } hsio = syscon_regmap_lookup_by_compatible("mscc,ocelot-hsio"); diff --git a/drivers/net/ethernet/mscc/ocelot_io.c b/drivers/net/ethernet/mscc/ocelot_io.c index c6db8ad31fdf..9a9a6766c231 100644 --- a/drivers/net/ethernet/mscc/ocelot_io.c +++ b/drivers/net/ethernet/mscc/ocelot_io.c @@ -97,20 +97,16 @@ static struct regmap_config ocelot_regmap_config = { .reg_stride = 4, }; -struct regmap *ocelot_io_platform_init(struct ocelot *ocelot, - struct platform_device *pdev, - const char *name) +struct regmap *ocelot_io_init(struct ocelot *ocelot, struct resource *res) { - struct resource *res; void __iomem *regs; - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, name); regs = devm_ioremap_resource(ocelot->dev, res); if (IS_ERR(regs)) return ERR_CAST(regs); - ocelot_regmap_config.name = name; - return devm_regmap_init_mmio(ocelot->dev, regs, - &ocelot_regmap_config); + ocelot_regmap_config.name = res->name; + + return devm_regmap_init_mmio(ocelot->dev, regs, &ocelot_regmap_config); } -EXPORT_SYMBOL(ocelot_io_platform_init); +EXPORT_SYMBOL(ocelot_io_init); -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil ` (2 preceding siblings ...) 2019-06-21 15:38 ` [PATCH net-next 3/6] ocelot: Factor out resource ioremap and regmap init common code Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-21 16:49 ` Andrew Lunn 2019-06-21 15:38 ` [PATCH net-next 5/6] dt-bindings: net: Add DT bindings for Microsemi Felix Switch Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver Claudiu Manoil 5 siblings, 1 reply; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver Add the switch device node, available on PF5, so that the switch port sub-nodes (net devices) can be linked to corresponding board specific phy nodes (external ports) or have their link mode defined (internal ports). The switch device features 6 ports, 4 with external links and 2 internally facing to the ls1028a SoC and connected via fixed links to 2 internal enetc ethernet controller ports. Add the corresponding enetc internal port device nodes, mapped to PF2 and PF6 PCIe functions. And don't forget to enable the 4MB BAR4 in the root complex ECAM space, where the switch registers are mapped. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- .../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 58 ++++++++++++++++++- 1 file changed, 57 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi index 4cdf84c63320..2462dd936212 100644 --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi @@ -421,7 +421,9 @@ /* PF1: VF0-1 BAR0 - non-prefetchable memory */ 0x82000000 0x0 0x00000000 0x1 0xf8210000 0x0 0x020000 /* PF1: VF0-1 BAR2 - prefetchable memory */ - 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000>; + 0xc2000000 0x0 0x00000000 0x1 0xf8230000 0x0 0x020000 + /* BAR4 (PF5) - non-prefetchable memory */ + 0x82000000 0x0 0x00000000 0x1 0xfc000000 0x0 0x400000>; enetc_port0: ethernet@0,0 { compatible = "fsl,enetc"; @@ -431,12 +433,66 @@ compatible = "fsl,enetc"; reg = <0x000100 0 0 0 0>; }; + ethernet@0,2 { + compatible = "fsl,enetc"; + reg = <0x000200 0 0 0 0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; ethernet@0,4 { compatible = "fsl,enetc-ptp"; reg = <0x000400 0 0 0 0>; clocks = <&clockgen 4 0>; little-endian; }; + switch@0,5 { + compatible = "mscc,felix-switch"; + reg = <0x000500 0 0 0 0>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + /* external ports */ + switch_port0: port@0 { + reg = <0>; + }; + switch_port1: port@1 { + reg = <1>; + }; + switch_port2: port@2 { + reg = <2>; + }; + switch_port3: port@3 { + reg = <3>; + }; + /* internal to-cpu ports */ + port@4 { + reg = <4>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + port@5 { + reg = <5>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + ethernet@0,6 { + compatible = "fsl,enetc"; + reg = <0x000600 0 0 0 0>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; }; }; }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-21 15:38 ` [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node Claudiu Manoil @ 2019-06-21 16:49 ` Andrew Lunn 2019-06-24 11:45 ` Claudiu Manoil 0 siblings, 1 reply; 25+ messages in thread From: Andrew Lunn @ 2019-06-21 16:49 UTC (permalink / raw) To: Claudiu Manoil Cc: David S . Miller, devicetree, Alexandre Belloni, netdev, alexandru.marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote: > The switch device features 6 ports, 4 with external links > and 2 internally facing to the ls1028a SoC and connected via > fixed links to 2 internal enetc ethernet controller ports. Hi Claudiu > + switch@0,5 { > + compatible = "mscc,felix-switch"; > + reg = <0x000500 0 0 0 0>; > + > + ethernet-ports { > + #address-cells = <1>; > + #size-cells = <0>; > + > + /* external ports */ > + switch_port0: port@0 { > + reg = <0>; > + }; > + switch_port1: port@1 { > + reg = <1>; > + }; > + switch_port2: port@2 { > + reg = <2>; > + }; > + switch_port3: port@3 { > + reg = <3>; > + }; > + /* internal to-cpu ports */ > + port@4 { > + reg = <4>; > + fixed-link { > + speed = <1000>; > + full-duplex; > + }; > + }; > + port@5 { > + reg = <5>; > + fixed-link { > + speed = <1000>; > + full-duplex; > + }; > + }; > + }; > + }; This sounds like a DSA setup, where you have SoC ports connected to the switch. With DSA, the CPU ports of the switch are special. We don't create netdev's for them, the binding explicitly list which SoC interface they are bound to, etc. What model are you using here? I'm just trying to understand the setup to ensure it is consistent with the swichdev model. Thanks Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-21 16:49 ` Andrew Lunn @ 2019-06-24 11:45 ` Claudiu Manoil 2019-06-24 11:55 ` Alexandre Belloni 0 siblings, 1 reply; 25+ messages in thread From: Claudiu Manoil @ 2019-06-24 11:45 UTC (permalink / raw) To: Andrew Lunn Cc: David S . Miller, devicetree, Alexandre Belloni, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel Hi Andrew, >-----Original Message----- >From: Andrew Lunn <andrew@lunn.ch> >Sent: Friday, June 21, 2019 7:50 PM >To: Claudiu Manoil <claudiu.manoil@nxp.com> >Cc: David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org; >Alexandre Belloni <alexandre.belloni@bootlin.com>; netdev@vger.kernel.org; >Alexandru Marginean <alexandru.marginean@nxp.com>; linux- >kernel@vger.kernel.org; UNGLinuxDriver@microchip.com; Allan Nielsen ><Allan.Nielsen@microsemi.com>; Rob Herring <robh+dt@kernel.org>; linux- >arm-kernel@lists.infradead.org >Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port >DT node > >On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote: >> The switch device features 6 ports, 4 with external links >> and 2 internally facing to the ls1028a SoC and connected via >> fixed links to 2 internal enetc ethernet controller ports. > >Hi Claudiu > >> + switch@0,5 { >> + compatible = "mscc,felix-switch"; >> + reg = <0x000500 0 0 0 0>; >> + >> + ethernet-ports { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + /* external ports */ >> + switch_port0: port@0 { >> + reg = <0>; >> + }; >> + switch_port1: port@1 { >> + reg = <1>; >> + }; >> + switch_port2: port@2 { >> + reg = <2>; >> + }; >> + switch_port3: port@3 { >> + reg = <3>; >> + }; >> + /* internal to-cpu ports */ >> + port@4 { >> + reg = <4>; >> + fixed-link { >> + speed = <1000>; >> + full-duplex; >> + }; >> + }; >> + port@5 { >> + reg = <5>; >> + fixed-link { >> + speed = <1000>; >> + full-duplex; >> + }; >> + }; >> + }; >> + }; > >This sounds like a DSA setup, where you have SoC ports connected to >the switch. With DSA, the CPU ports of the switch are special. We >don't create netdev's for them, the binding explicitly list which SoC >interface they are bound to, etc. > >What model are you using here? I'm just trying to understand the setup >to ensure it is consistent with the swichdev model. > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) connected inside the SoC via SGMII links to 2 of the switch ports, one of these switch ports can be configured as CPU port (with follow-up patches). This configuration may look prettier on DSA, but the main restriction here is that the entire functionality is provided by the ocelot driver which is a switchdev driver. I don't think it would be a good idea to copy-paste code from ocelot to a separate dsa driver. Thanks for the review. Claudiu ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 11:45 ` Claudiu Manoil @ 2019-06-24 11:55 ` Alexandre Belloni 2019-06-24 14:26 ` Andrew Lunn 0 siblings, 1 reply; 25+ messages in thread From: Alexandre Belloni @ 2019-06-24 11:55 UTC (permalink / raw) To: Claudiu Manoil Cc: Andrew Lunn, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On 24/06/2019 11:45:37+0000, Claudiu Manoil wrote: > Hi Andrew, > > >-----Original Message----- > >From: Andrew Lunn <andrew@lunn.ch> > >Sent: Friday, June 21, 2019 7:50 PM > >To: Claudiu Manoil <claudiu.manoil@nxp.com> > >Cc: David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org; > >Alexandre Belloni <alexandre.belloni@bootlin.com>; netdev@vger.kernel.org; > >Alexandru Marginean <alexandru.marginean@nxp.com>; linux- > >kernel@vger.kernel.org; UNGLinuxDriver@microchip.com; Allan Nielsen > ><Allan.Nielsen@microsemi.com>; Rob Herring <robh+dt@kernel.org>; linux- > >arm-kernel@lists.infradead.org > >Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port > >DT node > > > >On Fri, Jun 21, 2019 at 06:38:50PM +0300, Claudiu Manoil wrote: > >> The switch device features 6 ports, 4 with external links > >> and 2 internally facing to the ls1028a SoC and connected via > >> fixed links to 2 internal enetc ethernet controller ports. > > > >Hi Claudiu > > > >> + switch@0,5 { > >> + compatible = "mscc,felix-switch"; > >> + reg = <0x000500 0 0 0 0>; > >> + > >> + ethernet-ports { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + /* external ports */ > >> + switch_port0: port@0 { > >> + reg = <0>; > >> + }; > >> + switch_port1: port@1 { > >> + reg = <1>; > >> + }; > >> + switch_port2: port@2 { > >> + reg = <2>; > >> + }; > >> + switch_port3: port@3 { > >> + reg = <3>; > >> + }; > >> + /* internal to-cpu ports */ > >> + port@4 { > >> + reg = <4>; > >> + fixed-link { > >> + speed = <1000>; > >> + full-duplex; > >> + }; > >> + }; > >> + port@5 { > >> + reg = <5>; > >> + fixed-link { > >> + speed = <1000>; > >> + full-duplex; > >> + }; > >> + }; > >> + }; > >> + }; > > > >This sounds like a DSA setup, where you have SoC ports connected to > >the switch. With DSA, the CPU ports of the switch are special. We > >don't create netdev's for them, the binding explicitly list which SoC > >interface they are bound to, etc. > > > >What model are you using here? I'm just trying to understand the setup > >to ensure it is consistent with the swichdev model. > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > connected inside the SoC via SGMII links to 2 of the switch ports, one of > these switch ports can be configured as CPU port (with follow-up patches). > > This configuration may look prettier on DSA, but the main restriction here > is that the entire functionality is provided by the ocelot driver which is a > switchdev driver. I don't think it would be a good idea to copy-paste code > from ocelot to a separate dsa driver. > We should probably make the ocelot driver a DSA driver then... -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 11:55 ` Alexandre Belloni @ 2019-06-24 14:26 ` Andrew Lunn 2019-06-24 15:23 ` Allan W. Nielsen 0 siblings, 1 reply; 25+ messages in thread From: Andrew Lunn @ 2019-06-24 14:26 UTC (permalink / raw) To: Alexandre Belloni Cc: Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > > connected inside the SoC via SGMII links to 2 of the switch ports, one of > > these switch ports can be configured as CPU port (with follow-up patches). > > > > This configuration may look prettier on DSA, but the main restriction here > > is that the entire functionality is provided by the ocelot driver which is a > > switchdev driver. I don't think it would be a good idea to copy-paste code > > from ocelot to a separate dsa driver. > > > > We should probably make the ocelot driver a DSA driver then... Hi Claudiu, Alexandre An important part of DSA is being able to direct frames out specific ports when they ingress via the CPU port. Does the silicon support this? At the moment, i think it is using polled IO. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 14:26 ` Andrew Lunn @ 2019-06-24 15:23 ` Allan W. Nielsen 2019-06-24 16:24 ` Andrew Lunn 0 siblings, 1 reply; 25+ messages in thread From: Allan W. Nielsen @ 2019-06-24 15:23 UTC (permalink / raw) To: Andrew Lunn Cc: Alexandre Belloni, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel Hi Andrew, The 06/24/2019 16:26, Andrew Lunn wrote: > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of > > > these switch ports can be configured as CPU port (with follow-up patches). > > > > > > This configuration may look prettier on DSA, but the main restriction here > > > is that the entire functionality is provided by the ocelot driver which is a > > > switchdev driver. I don't think it would be a good idea to copy-paste code > > > from ocelot to a separate dsa driver. > > > > > > > We should probably make the ocelot driver a DSA driver then... > An important part of DSA is being able to direct frames out specific > ports when they ingress via the CPU port. Does the silicon support > this? At the moment, i think it is using polled IO. That is supported, it requires a bit of initial configuration of the Chip, but nothing big (I believe this configuration is part of Claudiu's change-set). But how do you envision this done? - Let the existing SwitchDev driver and the DSA driver use a set of common functions. - Convert the existing Ocelot driver from SwitchDev to DSA - Fork (copy) the existing driver of Ocelot, and modify it as needed for the Felix driver My guess is the first one, but I would like to understand what you have in mind. BTW: The Ocelot switch does exist in an other (register compatible) version without the MIPS CPU. That version would use a MAC-2-MAC connection to an external CPU, and would fit the DSA model. And we have been considering how to best represent that version in the kernel. /Allan ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 15:23 ` Allan W. Nielsen @ 2019-06-24 16:24 ` Andrew Lunn 2019-06-24 18:26 ` Alexandre Belloni 0 siblings, 1 reply; 25+ messages in thread From: Andrew Lunn @ 2019-06-24 16:24 UTC (permalink / raw) To: Allan W. Nielsen Cc: Alexandre Belloni, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote: > Hi Andrew, > > The 06/24/2019 16:26, Andrew Lunn wrote: > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of > > > > these switch ports can be configured as CPU port (with follow-up patches). > > > > > > > > This configuration may look prettier on DSA, but the main restriction here > > > > is that the entire functionality is provided by the ocelot driver which is a > > > > switchdev driver. I don't think it would be a good idea to copy-paste code > > > > from ocelot to a separate dsa driver. > > > > > > > > > > We should probably make the ocelot driver a DSA driver then... > > An important part of DSA is being able to direct frames out specific > > ports when they ingress via the CPU port. Does the silicon support > > this? At the moment, i think it is using polled IO. > > That is supported, it requires a bit of initial configuration of the Chip, but > nothing big (I believe this configuration is part of Claudiu's change-set). > > But how do you envision this done? > > - Let the existing SwitchDev driver and the DSA driver use a set of common > functions. > - Convert the existing Ocelot driver from SwitchDev to DSA > - Fork (copy) the existing driver of Ocelot, and modify it as needed for the > Felix driver > > My guess is the first one, but I would like to understand what you have in mind. I don't know the various architectures the switch is used in. But it does seem like a core library, and then a switchdev wrapper for Ocelot and a DSA wrapper for Felix would make sense. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 16:24 ` Andrew Lunn @ 2019-06-24 18:26 ` Alexandre Belloni 2019-07-04 23:32 ` Vladimir Oltean 0 siblings, 1 reply; 25+ messages in thread From: Alexandre Belloni @ 2019-06-24 18:26 UTC (permalink / raw) To: Andrew Lunn Cc: Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On 24/06/2019 18:24:31+0200, Andrew Lunn wrote: > On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote: > > Hi Andrew, > > > > The 06/24/2019 16:26, Andrew Lunn wrote: > > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > > > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of > > > > > these switch ports can be configured as CPU port (with follow-up patches). > > > > > > > > > > This configuration may look prettier on DSA, but the main restriction here > > > > > is that the entire functionality is provided by the ocelot driver which is a > > > > > switchdev driver. I don't think it would be a good idea to copy-paste code > > > > > from ocelot to a separate dsa driver. > > > > > > > > > > > > > We should probably make the ocelot driver a DSA driver then... > > > An important part of DSA is being able to direct frames out specific > > > ports when they ingress via the CPU port. Does the silicon support > > > this? At the moment, i think it is using polled IO. > > > > That is supported, it requires a bit of initial configuration of the Chip, but > > nothing big (I believe this configuration is part of Claudiu's change-set). > > > > But how do you envision this done? > > > > - Let the existing SwitchDev driver and the DSA driver use a set of common > > functions. > > - Convert the existing Ocelot driver from SwitchDev to DSA > > - Fork (copy) the existing driver of Ocelot, and modify it as needed for the > > Felix driver > > > > My guess is the first one, but I would like to understand what you have in mind. > > I don't know the various architectures the switch is used in. But it > does seem like a core library, and then a switchdev wrapper for Ocelot > and a DSA wrapper for Felix would make sense. Ocelot could also be used in a DSA setting where one port can be connected to an external MAC and be used to inject/extract frames to/from any other ports. In that case, the IFH would serve as the DSA tag. -- Alexandre Belloni, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-06-24 18:26 ` Alexandre Belloni @ 2019-07-04 23:32 ` Vladimir Oltean 2019-07-05 4:49 ` Andrew Lunn 0 siblings, 1 reply; 25+ messages in thread From: Vladimir Oltean @ 2019-07-04 23:32 UTC (permalink / raw) To: Alexandre Belloni Cc: Andrew Lunn, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On Tue, 25 Jun 2019 at 00:23, Alexandre Belloni <alexandre.belloni@bootlin.com> wrote: > > On 24/06/2019 18:24:31+0200, Andrew Lunn wrote: > > On Mon, Jun 24, 2019 at 05:23:45PM +0200, Allan W. Nielsen wrote: > > > Hi Andrew, > > > > > > The 06/24/2019 16:26, Andrew Lunn wrote: > > > > > > Yeah, there are 2 ethernet controller ports (managed by the enetc driver) > > > > > > connected inside the SoC via SGMII links to 2 of the switch ports, one of > > > > > > these switch ports can be configured as CPU port (with follow-up patches). > > > > > > > > > > > > This configuration may look prettier on DSA, but the main restriction here > > > > > > is that the entire functionality is provided by the ocelot driver which is a > > > > > > switchdev driver. I don't think it would be a good idea to copy-paste code > > > > > > from ocelot to a separate dsa driver. > > > > > > > > > > > > > > > > We should probably make the ocelot driver a DSA driver then... > > > > An important part of DSA is being able to direct frames out specific > > > > ports when they ingress via the CPU port. Does the silicon support > > > > this? At the moment, i think it is using polled IO. > > > > > > That is supported, it requires a bit of initial configuration of the Chip, but > > > nothing big (I believe this configuration is part of Claudiu's change-set). > > > > > > But how do you envision this done? > > > > > > - Let the existing SwitchDev driver and the DSA driver use a set of common > > > functions. > > > - Convert the existing Ocelot driver from SwitchDev to DSA > > > - Fork (copy) the existing driver of Ocelot, and modify it as needed for the > > > Felix driver > > > > > > My guess is the first one, but I would like to understand what you have in mind. > > > > I don't know the various architectures the switch is used in. But it > > does seem like a core library, and then a switchdev wrapper for Ocelot > > and a DSA wrapper for Felix would make sense. > > Ocelot could also be used in a DSA setting where one port can be > connected to an external MAC and be used to inject/extract frames > to/from any other ports. In that case, the IFH would serve as the DSA > tag. > > > -- > Alexandre Belloni, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com Hi everyone, Thank you for the nice discussion. I've been talking off-list to Claudiu and Alexandru about switchdev vs DSA for the Felix/Ocelot switches. My initial reaction was the same as Andrew's - there's a CPU-facing Ethernet MAC with some vendor-defined injection and extraction headers? Sounds like DSA. But then we discussed about what DSA for Felix/Ocelot would look like. Here are some points to consider: - DSA is typically used for discrete switches, switchdev is typically used for embedded ones. As far as I understand from Allan's message, Ocelot is really an entire switching SoC that's running Linux inside (on the MIPS CPU) with a switchdev driver. There is no (mainline?) driver that would control the Ocelot SoC from a higher-level Linux system. The latter would (maybe) fit DSA more. - The D in DSA is for cascaded switches. Apart from the absence of such a "Ocelot SoC" driver (which maybe can be written, I don't know), I think the switching core itself has some fundamental limitations that make a DSA implementation questionable: 1. The switch has a single port which can apply these vendor tags. Also the injection header is different than the extraction header. See more at #4. 2. The switch will tag all frames that go upstream on this port towards the CPU, no matter what source port they came from. It can't be told "hey, don't add a tag for frames coming from this downstream-facing port, because it's a DSA port and not front-panel, so there's another switch underneath you who already added a tag to the frame". So frames that arrive at the CPU through an array of N cascaded Felix/Ocelot switches will need to be peeled off, one by one, by N vendor tags. 3. The extraction header does not contain a field for the "switch id", only for the "source port". This means that if you want to figure out the switch id, you really *need* to make a topology out of those stacked vendor tags and figure out which switch it was by counting the tags. It also means that you can only have Felix/Ocelot in a linear topology. 4. The switch cannot parse its own vendor tags. This is a big one, because it means that for an autonomously forwarded frame which transits two cascaded switches but doesn't reach the CPU, there is no one in the path who's going to consume the vendor tag. So the frame will exit the other front-panel port with extra bytes in it. Ok, let's say that all of the above limitations have one thing in common - the vendor tags aren't really thought out with DSA-like setups in mind. In theory it's possible to not use the native tags and instead implement a dsa_8021q tagger for it. But then, RX timestamps for PTP are also transmitted to the CPU through this vendor header, and losing PTP is a big no-no. So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of sense if the whole purpose is to hide the CPU-facing netdev. In a cascaded setup, these switches could only sit at the top of tree, and ironically, they'd be better modeled as a switchdev DSA master port than part of the DSA tree itself. Put these switches anywhere else in the tree and they're just troublemakers. As for the LS1028A, I think that connecting this embedded switch via two Ethernet MACs is just poorly thought out design, but that doesn't mean DSA is going to help it in any way other than perhaps cosmetic. Regards, -Vladimir ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-04 23:32 ` Vladimir Oltean @ 2019-07-05 4:49 ` Andrew Lunn 2019-07-05 8:37 ` Claudiu Manoil 2019-07-05 9:08 ` Vladimir Oltean 0 siblings, 2 replies; 25+ messages in thread From: Andrew Lunn @ 2019-07-05 4:49 UTC (permalink / raw) To: Vladimir Oltean Cc: Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel Hi Vladimir > - DSA is typically used for discrete switches, switchdev is typically > used for embedded ones. Typically DSA is for discrete switches, but not exclusively. The b53/SF2 is embedded in a number of Broadcom SoCs. So this is no different to Ocelot, except ARM vs MIPS. Also, i would disagree that switchdev is used for embedded ones. Mellonex devices are discrete, on a PCIe bus. I believe Netronome devices are also discrete PCIe devices. In fact, i think ocelot is the only embedded switchdev switch. So embedded vs discrete plays no role here at all. > - The D in DSA is for cascaded switches. Apart from the absence of > such a "Ocelot SoC" driver (which maybe can be written, I don't know), > I think the switching core itself has some fundamental limitations > that make a DSA implementation questionable: There is no requirement to implement D in DSA. In fact, only Marvell does. None of the other switches do. And you will also find that most boards with a Marvell switch use a single device. D in DSA is totally optional. In fact, DSA is built from the ground up that nearly everything is optional. Take a look at mv88e6060, as an example. It implements nearly nothing. It cannot even offload a bridge to the switch. > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of > sense if the whole purpose is to hide the CPU-facing netdev. You actually convinced me the exact opposite. You described the headers which are needed to implement DSA. The switch sounds like it can do what DSA requires. So DSA is the correct model. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 4:49 ` Andrew Lunn @ 2019-07-05 8:37 ` Claudiu Manoil 2019-07-05 13:19 ` Andrew Lunn 2019-07-05 9:08 ` Vladimir Oltean 1 sibling, 1 reply; 25+ messages in thread From: Claudiu Manoil @ 2019-07-05 8:37 UTC (permalink / raw) To: Andrew Lunn, Vladimir Oltean Cc: Alexandre Belloni, Allan W. Nielsen, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel >-----Original Message----- >From: Andrew Lunn <andrew@lunn.ch> >Sent: Friday, July 5, 2019 7:50 AM >To: Vladimir Oltean <olteanv@gmail.com> >Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>; Allan W. Nielsen ><allan.nielsen@microchip.com>; Claudiu Manoil <claudiu.manoil@nxp.com>; >David S . Miller <davem@davemloft.net>; devicetree@vger.kernel.org; >netdev@vger.kernel.org; Alexandru Marginean ><alexandru.marginean@nxp.com>; linux-kernel@vger.kernel.org; >UNGLinuxDriver@microchip.com; Allan Nielsen ><Allan.Nielsen@microsemi.com>; Rob Herring <robh+dt@kernel.org>; linux- >arm-kernel@lists.infradead.org >Subject: Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port >DT node > >Hi Vladimir > >> - DSA is typically used for discrete switches, switchdev is typically >> used for embedded ones. > >Typically DSA is for discrete switches, but not exclusively. The >b53/SF2 is embedded in a number of Broadcom SoCs. So this is no >different to Ocelot, except ARM vs MIPS. Also, i would disagree that >switchdev is used for embedded ones. Mellonex devices are discrete, on >a PCIe bus. I believe Netronome devices are also discrete PCIe >devices. In fact, i think ocelot is the only embedded switchdev >switch. > >So embedded vs discrete plays no role here at all. > >> - The D in DSA is for cascaded switches. Apart from the absence of >> such a "Ocelot SoC" driver (which maybe can be written, I don't know), >> I think the switching core itself has some fundamental limitations >> that make a DSA implementation questionable: > >There is no requirement to implement D in DSA. In fact, only Marvell >does. None of the other switches do. And you will also find that most >boards with a Marvell switch use a single device. D in DSA is totally >optional. In fact, DSA is built from the ground up that nearly >everything is optional. Take a look at mv88e6060, as an example. It >implements nearly nothing. It cannot even offload a bridge to the >switch. > Nice discussion, again, but there's a missing point that has not been brought up yet. We actually intend to support the following hardware configuration: a single PCI device consisting of the Microsemi's switch core and our DMA rings. The hardware supports this configuration into a single PCI function (PF), with a unique PCI function id (0xe111), so that the same driver has access to both switch registers and DMA rings connected to the CPU port. This device would qualify as a switchdev device, and we can simply reuse the existing ocelot code for the switch core part. The initial patch set was the first step in supporting the switch core on our platform, we just need to add the support for the DMA rings part, to make it a complete switchdev solution. Thanks, Claudiu ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 8:37 ` Claudiu Manoil @ 2019-07-05 13:19 ` Andrew Lunn 0 siblings, 0 replies; 25+ messages in thread From: Andrew Lunn @ 2019-07-05 13:19 UTC (permalink / raw) To: Claudiu Manoil Cc: Vladimir Oltean, Alexandre Belloni, Allan W. Nielsen, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel > Nice discussion, again, but there's a missing point that has not been > brought up yet. We actually intend to support the following hardware > configuration: a single PCI device consisting of the Microsemi's switch core > and our DMA rings. > The hardware supports this configuration into a single PCI function (PF), > with a unique PCI function id (0xe111), so that the same driver has access to > both switch registers and DMA rings connected to the CPU port. This device > would qualify as a switchdev device, and we can simply reuse the existing > ocelot code for the switch core part. The initial patch set was the first step in > supporting the switch core on our platform, we just need to add the support > for the DMA rings part, to make it a complete switchdev solution. Hi Claudiu It sound like in the end you will have a core library and then two drivers wrapped around it, giving a pure switchdev device with polled IO or DMA, and a DSA driver using a CPU port. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 4:49 ` Andrew Lunn 2019-07-05 8:37 ` Claudiu Manoil @ 2019-07-05 9:08 ` Vladimir Oltean 2019-07-05 14:15 ` Andrew Lunn 2019-07-05 16:03 ` Florian Fainelli 1 sibling, 2 replies; 25+ messages in thread From: Vladimir Oltean @ 2019-07-05 9:08 UTC (permalink / raw) To: Andrew Lunn Cc: Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel Hi Andrew, On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote: > > Hi Vladimir > > > - DSA is typically used for discrete switches, switchdev is typically > > used for embedded ones. > > Typically DSA is for discrete switches, but not exclusively. The > b53/SF2 is embedded in a number of Broadcom SoCs. So this is no > different to Ocelot, except ARM vs MIPS. Also, i would disagree that > switchdev is used for embedded ones. Mellonex devices are discrete, on > a PCIe bus. I believe Netronome devices are also discrete PCIe > devices. In fact, i think ocelot is the only embedded switchdev > switch. > > So embedded vs discrete plays no role here at all. > drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev driver for an embedded switch. I would give it to you that the sample size is probably too small to say 'typically', but my point was that in order to support cascaded switches it makes more sense for those to be discrete. > > - The D in DSA is for cascaded switches. Apart from the absence of > > such a "Ocelot SoC" driver (which maybe can be written, I don't know), > > I think the switching core itself has some fundamental limitations > > that make a DSA implementation questionable: > > There is no requirement to implement D in DSA. In fact, only Marvell > does. None of the other switches do. And you will also find that most > boards with a Marvell switch use a single device. D in DSA is totally > optional. In fact, DSA is built from the ground up that nearly > everything is optional. Take a look at mv88e6060, as an example. It > implements nearly nothing. It cannot even offload a bridge to the > switch. > Let me see if I get your point. The D is optional, and the S is optional. So what's left? :) Also, there's a big difference between "the hardware can't do it" and "the driver doesn't implement it". If I follow your argument, would you write a DSA driver for a device that doesn't do L2 switching? Along that same line, what benefit does the DSA model bring to a switch that can't do cascading, compared to switchdev? I'm asking this as a user, not as a developer. > > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of > > sense if the whole purpose is to hide the CPU-facing netdev. > > You actually convinced me the exact opposite. You described the > headers which are needed to implement DSA. The switch sounds like it > can do what DSA requires. So DSA is the correct model. > > Andrew Somebody actually asked, with the intention of building a board, if it's possible to cascade the LS1028A embedded switch (Felix) with discrete SJA1105 devices - Felix being at the top of the switch tree. Does the DSA model support heterogeneous setups (parsing stacked headers)? I can't tell if that's how EDSA tags work. With switchdev for Felix there wouldn't be any problem - it just wouldn't be part of the DSA tree and its own driver would remove its tags before DSA would look at the rest. Regards, -Vladimir ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 9:08 ` Vladimir Oltean @ 2019-07-05 14:15 ` Andrew Lunn 2019-07-05 16:03 ` Florian Fainelli 1 sibling, 0 replies; 25+ messages in thread From: Andrew Lunn @ 2019-07-05 14:15 UTC (permalink / raw) To: Vladimir Oltean Cc: Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel > Let me see if I get your point. > The D is optional, and the S is optional. So what's left? :) A collection of interfaces. switchdev and by extension DSA is all about using hardware as an accelerator. Linux can do switching in software. It can do routing in software, it can do bonding in software, etc. switchdev gives you an API to offload this to hardware. And if the hardware or the driver does not support it, linux will just keep on doing it in software. Once you get the idea it is just an accelerator, the rest falls into place. Why there are no new configuration tools, why we expect network daemons to just work, why users don't need to learn anything new. It is all just linux networking as normal. > Also, there's a big difference between "the hardware can't do it" and > "the driver doesn't implement it". If I follow your argument, would > you write a DSA driver for a device that doesn't do L2 switching? Sure i would. Such a device is a port multiplexor. The user sees the user ports as linux interfaces. They can use those interfaces just like any other linux interfaces. Configure them using iproute2, add them to bridges, run bonding, etc. All just linux as normal. > Along that same line, what benefit does the DSA model bring to a > switch that can't do cascading, compared to switchdev? I'm asking this > as a user, not as a developer. DSA builds on top of switchdev. switchdev gives you an API to offload things which are happening in software to the hardware. It is the glue which allows you to configure the accelerator. There is also a common pattern for some switches. They connect a switch port MAC to a host port MAC, so that frames can be passed from the CPU to the switch. This pattern is common enough that infrastructure has been put in place to support this model. That infrastructure is DSA. But that is mostly about details for the driver writer. From the users perspective, you have a bunch of interfaces which you just use as normal, and some stuff can get accelerated by the hardware. We don't want the user to have to known about, or do anything, with the host port or the switch port it is connected to. DSA very nearly takes care of everything to do with those two. The only thing you need to do is configure the master interface up. Then things just work as a bunch of Linux interfaces. Now think about a pure switchdev switch, with a port connected to the host. The model breaks down. How do you use that link to the switch? It is just a plane link. You would not have tagging in operation. So you cannot send frames out specific ports. In order to do that, you need to add vlans, and configure the switch to map vlans to ports, etc. You also then have two linux interfaces representing one port. The pure switchdev interface, and the VLAN interface. That is going to confuse the user. You SNMP agent is not just going to work. You get the statistics from the pure switchdev interface, but the IP configuration from the vlan interface? How do you bridge two ports together? You need to put the same VLAN on two interfaces. Where as the DSA model you just use linux as normal and create a bridge, add the two interfaces, and then the stack transparently offloads it to the accelerator. How does STP work? Using DSA without using the D means switch ports just work as linux interfaces. > > > > So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of > > > sense if the whole purpose is to hide the CPU-facing netdev. > > > > You actually convinced me the exact opposite. You described the > > headers which are needed to implement DSA. The switch sounds like it > > can do what DSA requires. So DSA is the correct model. > > > > Andrew > > Somebody actually asked, with the intention of building a board, if > it's possible to cascade the LS1028A embedded switch (Felix) with > discrete SJA1105 devices - Felix being at the top of the switch tree. Florian has done something very similar. He used a Broadcom SoC with an in built SF2 switch, and an external B53 roboswitch connected to one of the SF2 ports. But in that setup, the master interface for the b53 is a slave port of the SF2. Configure everything in device tree, bring up the SoC master interface, then the SF2 port acting as a master interface for the B53, and everything just worked. You have a bunch of Linux interfaces you can just use as normal. This is not using D in DSA. It is two instances of DSA. But because the model is that you get normal linux interfaces, it just works. I don't see why you cannot do the same with a LS1028A and a SJA1105. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 9:08 ` Vladimir Oltean 2019-07-05 14:15 ` Andrew Lunn @ 2019-07-05 16:03 ` Florian Fainelli 2019-07-07 21:00 ` Vladimir Oltean 1 sibling, 1 reply; 25+ messages in thread From: Florian Fainelli @ 2019-07-05 16:03 UTC (permalink / raw) To: Vladimir Oltean, Andrew Lunn Cc: Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On 7/5/2019 2:08 AM, Vladimir Oltean wrote: > Hi Andrew, > > On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote: >> >> Hi Vladimir >> >>> - DSA is typically used for discrete switches, switchdev is typically >>> used for embedded ones. >> >> Typically DSA is for discrete switches, but not exclusively. The >> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no >> different to Ocelot, except ARM vs MIPS. Also, i would disagree that >> switchdev is used for embedded ones. Mellonex devices are discrete, on >> a PCIe bus. I believe Netronome devices are also discrete PCIe >> devices. In fact, i think ocelot is the only embedded switchdev >> switch. >> >> So embedded vs discrete plays no role here at all. >> > > drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev > driver for an embedded switch. > I would give it to you that the sample size is probably too small to > say 'typically', but my point was that in order to support cascaded > switches it makes more sense for those to be discrete. > >>> - The D in DSA is for cascaded switches. Apart from the absence of >>> such a "Ocelot SoC" driver (which maybe can be written, I don't know), >>> I think the switching core itself has some fundamental limitations >>> that make a DSA implementation questionable: >> >> There is no requirement to implement D in DSA. In fact, only Marvell >> does. None of the other switches do. And you will also find that most >> boards with a Marvell switch use a single device. D in DSA is totally >> optional. In fact, DSA is built from the ground up that nearly >> everything is optional. Take a look at mv88e6060, as an example. It >> implements nearly nothing. It cannot even offload a bridge to the >> switch. >> > > Let me see if I get your point. > The D is optional, and the S is optional. So what's left? :) > Also, there's a big difference between "the hardware can't do it" and > "the driver doesn't implement it". If I follow your argument, would > you write a DSA driver for a device that doesn't do L2 switching? > Along that same line, what benefit does the DSA model bring to a > switch that can't do cascading, compared to switchdev? I'm asking this > as a user, not as a developer. As an user, I don't think there are compelling arguments to either switchdev or DSA because the end result is the same: network devices that can offload "stuff". As a developer though, there is much less code to write with DSA than with switchdev to get your HW live. > >>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of >>> sense if the whole purpose is to hide the CPU-facing netdev. >> >> You actually convinced me the exact opposite. You described the >> headers which are needed to implement DSA. The switch sounds like it >> can do what DSA requires. So DSA is the correct model. >> >> Andrew > > Somebody actually asked, with the intention of building a board, if > it's possible to cascade the LS1028A embedded switch (Felix) with > discrete SJA1105 devices - Felix being at the top of the switch tree. > Does the DSA model support heterogeneous setups (parsing stacked > headers)? I can't tell if that's how EDSA tags work. With switchdev > for Felix there wouldn't be any problem - it just wouldn't be part of > the DSA tree and its own driver would remove its tags before DSA would > look at the rest. DSA not does not make any particular assumptions about how the stacking is done actually because each slave network device is expected to provided standard Ethernet frames to the network stack. How you get to that point is entirely specific to what the hardware can do. You do what Andrew described about one of my setup (bcm_sf2 w/ tagging enabled and b53 w/o tagging, see more below why [1]]) and both being discrete switch trees, with the master netdev of the b53 being a slave netdev provided by bcm_sf2. If your tagging protocol supports it you can make them part of the same DSA switch tree and just have them have different switch identifiers, that is what Marvell switches do and it works just great. In your case, I suppose you could even use double VLAN tagging to get such cascading to work, that would limit you to a two level of cascading, unless you invent something custom. [1]: The original Broadcom tag format introduced with BCM5325/5365 did support cascading in the same way that Marvell did where a switch identifier can be added in addition to a port number within the tag. The newest Broadcom tag that was introduced with 5395 and newer dropped support for the switch identifier and the switch will "terminate" the first (from start of Ethernet frame) tag that it receives. This is the reason why we need to disable tagging on the outermost B53 device that we are connected to. This means those network devices are mainly configuration endpoints and not passing data (DSA_TAG_PROTO_NONE), though we could use DSA_TAG_PROTO_8021Q and resolve that now. -- Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-05 16:03 ` Florian Fainelli @ 2019-07-07 21:00 ` Vladimir Oltean 2019-07-07 21:15 ` Florian Fainelli 0 siblings, 1 reply; 25+ messages in thread From: Vladimir Oltean @ 2019-07-07 21:00 UTC (permalink / raw) To: Florian Fainelli Cc: Andrew Lunn, Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <f.fainelli@gmail.com> wrote: > > > > On 7/5/2019 2:08 AM, Vladimir Oltean wrote: > > Hi Andrew, > > > > On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote: > >> > >> Hi Vladimir > >> > >>> - DSA is typically used for discrete switches, switchdev is typically > >>> used for embedded ones. > >> > >> Typically DSA is for discrete switches, but not exclusively. The > >> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no > >> different to Ocelot, except ARM vs MIPS. Also, i would disagree that > >> switchdev is used for embedded ones. Mellonex devices are discrete, on > >> a PCIe bus. I believe Netronome devices are also discrete PCIe > >> devices. In fact, i think ocelot is the only embedded switchdev > >> switch. > >> > >> So embedded vs discrete plays no role here at all. > >> > > > > drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev > > driver for an embedded switch. > > I would give it to you that the sample size is probably too small to > > say 'typically', but my point was that in order to support cascaded > > switches it makes more sense for those to be discrete. > > > >>> - The D in DSA is for cascaded switches. Apart from the absence of > >>> such a "Ocelot SoC" driver (which maybe can be written, I don't know), > >>> I think the switching core itself has some fundamental limitations > >>> that make a DSA implementation questionable: > >> > >> There is no requirement to implement D in DSA. In fact, only Marvell > >> does. None of the other switches do. And you will also find that most > >> boards with a Marvell switch use a single device. D in DSA is totally > >> optional. In fact, DSA is built from the ground up that nearly > >> everything is optional. Take a look at mv88e6060, as an example. It > >> implements nearly nothing. It cannot even offload a bridge to the > >> switch. > >> > > > > Let me see if I get your point. > > The D is optional, and the S is optional. So what's left? :) > > Also, there's a big difference between "the hardware can't do it" and > > "the driver doesn't implement it". If I follow your argument, would > > you write a DSA driver for a device that doesn't do L2 switching? > > Along that same line, what benefit does the DSA model bring to a > > switch that can't do cascading, compared to switchdev? I'm asking this > > as a user, not as a developer. > > As an user, I don't think there are compelling arguments to either > switchdev or DSA because the end result is the same: network devices > that can offload "stuff". As a developer though, there is much less code > to write with DSA than with switchdev to get your HW live. > > > > >>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of > >>> sense if the whole purpose is to hide the CPU-facing netdev. > >> > >> You actually convinced me the exact opposite. You described the > >> headers which are needed to implement DSA. The switch sounds like it > >> can do what DSA requires. So DSA is the correct model. > >> > >> Andrew > > > > Somebody actually asked, with the intention of building a board, if > > it's possible to cascade the LS1028A embedded switch (Felix) with > > discrete SJA1105 devices - Felix being at the top of the switch tree. > > Does the DSA model support heterogeneous setups (parsing stacked > > headers)? I can't tell if that's how EDSA tags work. With switchdev > > for Felix there wouldn't be any problem - it just wouldn't be part of > > the DSA tree and its own driver would remove its tags before DSA would > > look at the rest. > > DSA not does not make any particular assumptions about how the stacking > is done actually because each slave network device is expected to > provided standard Ethernet frames to the network stack. How you get to > that point is entirely specific to what the hardware can do. > > You do what Andrew described about one of my setup (bcm_sf2 w/ tagging > enabled and b53 w/o tagging, see more below why [1]]) and both being > discrete switch trees, with the master netdev of the b53 being a slave > netdev provided by bcm_sf2. If your tagging protocol supports it you can > make them part of the same DSA switch tree and just have them have > different switch identifiers, that is what Marvell switches do and it > works just great. In your case, I suppose you could even use double VLAN > tagging to get such cascading to work, that would limit you to a two > level of cascading, unless you invent something custom. > > [1]: The original Broadcom tag format introduced with BCM5325/5365 did > support cascading in the same way that Marvell did where a switch > identifier can be added in addition to a port number within the tag. The > newest Broadcom tag that was introduced with 5395 and newer dropped > support for the switch identifier and the switch will "terminate" the > first (from start of Ethernet frame) tag that it receives. This is the > reason why we need to disable tagging on the outermost B53 device that > we are connected to. This means those network devices are mainly > configuration endpoints and not passing data (DSA_TAG_PROTO_NONE), > though we could use DSA_TAG_PROTO_8021Q and resolve that now. > -- > Florian Thanks to both of you for sharing this trick, I don't think it's written "in the books". Given that you can choose the boundaries of a DSA tree at will depending on what suits the setup best (and e.g. turn a DSA link pair into a master and a CPU port pair which gains back introspection into that port's ethtool counters etc), I guess DSA doesn't really offer anything that raw switchdev drivers can't do (by reimplementing part of it), just that it's is more idiomatic for Ethernet-connected switches? If so, it's a bit strange that switchdev and DSA are not in fact unified, because as it is it creates false dichotomies. What about the other way around? What are the features that raw switchdev drivers (nfp, rocker, mlxsw) need that DSA can't offer them without breaking the general model? (apart from access to the raw ndo_start_xmit and a NAPI context for rcv) As for DSA being easier on the driver writer, I totally get that, but I think it isn't that much of an argument when the switchdev driver is already said and done, as in this case :) Regards, -Vladimir ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node 2019-07-07 21:00 ` Vladimir Oltean @ 2019-07-07 21:15 ` Florian Fainelli 0 siblings, 0 replies; 25+ messages in thread From: Florian Fainelli @ 2019-07-07 21:15 UTC (permalink / raw) To: Vladimir Oltean Cc: Andrew Lunn, Alexandre Belloni, Allan W. Nielsen, Claudiu Manoil, David S . Miller, devicetree, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, linux-arm-kernel On 7/7/2019 2:00 PM, Vladimir Oltean wrote: > On Fri, 5 Jul 2019 at 19:03, Florian Fainelli <f.fainelli@gmail.com> wrote: >> >> >> >> On 7/5/2019 2:08 AM, Vladimir Oltean wrote: >>> Hi Andrew, >>> >>> On Fri, 5 Jul 2019 at 07:49, Andrew Lunn <andrew@lunn.ch> wrote: >>>> >>>> Hi Vladimir >>>> >>>>> - DSA is typically used for discrete switches, switchdev is typically >>>>> used for embedded ones. >>>> >>>> Typically DSA is for discrete switches, but not exclusively. The >>>> b53/SF2 is embedded in a number of Broadcom SoCs. So this is no >>>> different to Ocelot, except ARM vs MIPS. Also, i would disagree that >>>> switchdev is used for embedded ones. Mellonex devices are discrete, on >>>> a PCIe bus. I believe Netronome devices are also discrete PCIe >>>> devices. In fact, i think ocelot is the only embedded switchdev >>>> switch. >>>> >>>> So embedded vs discrete plays no role here at all. >>>> >>> >>> drivers/staging/fsl-dpaa2/ethsw/ is another example of switchdev >>> driver for an embedded switch. >>> I would give it to you that the sample size is probably too small to >>> say 'typically', but my point was that in order to support cascaded >>> switches it makes more sense for those to be discrete. >>> >>>>> - The D in DSA is for cascaded switches. Apart from the absence of >>>>> such a "Ocelot SoC" driver (which maybe can be written, I don't know), >>>>> I think the switching core itself has some fundamental limitations >>>>> that make a DSA implementation questionable: >>>> >>>> There is no requirement to implement D in DSA. In fact, only Marvell >>>> does. None of the other switches do. And you will also find that most >>>> boards with a Marvell switch use a single device. D in DSA is totally >>>> optional. In fact, DSA is built from the ground up that nearly >>>> everything is optional. Take a look at mv88e6060, as an example. It >>>> implements nearly nothing. It cannot even offload a bridge to the >>>> switch. >>>> >>> >>> Let me see if I get your point. >>> The D is optional, and the S is optional. So what's left? :) >>> Also, there's a big difference between "the hardware can't do it" and >>> "the driver doesn't implement it". If I follow your argument, would >>> you write a DSA driver for a device that doesn't do L2 switching? >>> Along that same line, what benefit does the DSA model bring to a >>> switch that can't do cascading, compared to switchdev? I'm asking this >>> as a user, not as a developer. >> >> As an user, I don't think there are compelling arguments to either >> switchdev or DSA because the end result is the same: network devices >> that can offload "stuff". As a developer though, there is much less code >> to write with DSA than with switchdev to get your HW live. >> >>> >>>>> So my conclusion is that DSA for Felix/Ocelot doesn't make a lot of >>>>> sense if the whole purpose is to hide the CPU-facing netdev. >>>> >>>> You actually convinced me the exact opposite. You described the >>>> headers which are needed to implement DSA. The switch sounds like it >>>> can do what DSA requires. So DSA is the correct model. >>>> >>>> Andrew >>> >>> Somebody actually asked, with the intention of building a board, if >>> it's possible to cascade the LS1028A embedded switch (Felix) with >>> discrete SJA1105 devices - Felix being at the top of the switch tree. >>> Does the DSA model support heterogeneous setups (parsing stacked >>> headers)? I can't tell if that's how EDSA tags work. With switchdev >>> for Felix there wouldn't be any problem - it just wouldn't be part of >>> the DSA tree and its own driver would remove its tags before DSA would >>> look at the rest. >> >> DSA not does not make any particular assumptions about how the stacking >> is done actually because each slave network device is expected to >> provided standard Ethernet frames to the network stack. How you get to >> that point is entirely specific to what the hardware can do. >> >> You do what Andrew described about one of my setup (bcm_sf2 w/ tagging >> enabled and b53 w/o tagging, see more below why [1]]) and both being >> discrete switch trees, with the master netdev of the b53 being a slave >> netdev provided by bcm_sf2. If your tagging protocol supports it you can >> make them part of the same DSA switch tree and just have them have >> different switch identifiers, that is what Marvell switches do and it >> works just great. In your case, I suppose you could even use double VLAN >> tagging to get such cascading to work, that would limit you to a two >> level of cascading, unless you invent something custom. >> >> [1]: The original Broadcom tag format introduced with BCM5325/5365 did >> support cascading in the same way that Marvell did where a switch >> identifier can be added in addition to a port number within the tag. The >> newest Broadcom tag that was introduced with 5395 and newer dropped >> support for the switch identifier and the switch will "terminate" the >> first (from start of Ethernet frame) tag that it receives. This is the >> reason why we need to disable tagging on the outermost B53 device that >> we are connected to. This means those network devices are mainly >> configuration endpoints and not passing data (DSA_TAG_PROTO_NONE), >> though we could use DSA_TAG_PROTO_8021Q and resolve that now. >> -- >> Florian > > Thanks to both of you for sharing this trick, I don't think it's > written "in the books". > Given that you can choose the boundaries of a DSA tree at will > depending on what suits the setup best (and e.g. turn a DSA link pair > into a master and a CPU port pair which gains back introspection into > that port's ethtool counters etc), I guess DSA doesn't really offer > anything that raw switchdev drivers can't do (by reimplementing part > of it), just that it's is more idiomatic for Ethernet-connected > switches? > If so, it's a bit strange that switchdev and DSA are not in fact > unified, because as it is it creates false dichotomies. What about the > other way around? What are the features that raw switchdev drivers > (nfp, rocker, mlxsw) need that DSA can't offer them without breaking > the general model? (apart from access to the raw ndo_start_xmit and a > NAPI context for rcv) I don't think they need anything that DSA could not offer them, other than having the ability to complete bypass the net_device registration and standard methods offered by DSA and provide their own. > As for DSA being easier on the driver writer, I totally get that, but > I think it isn't that much of an argument when the switchdev driver is > already said and done, as in this case :) DSA and switchdev don't try to solve the same problems, switchdev is only about providing the mechanics by which the networking stack can offload certain objects: FDB, MDB, VLANs, VXLANs, bridge attributes etc towards capable devices. It is largely stateless and does not care so much about what kind of device is on the other end of the notifications it sends. DSA is all about creating a device driver model for Ethernet switches that follow the paradigm of having a seemingly standard Ethernet MAC (doing DMA) connected to one or more Ethernet switch devices and between those devices, a data path allows the identification of each Ethernet frame as ingressing/egressing towards a particular switch port in the fabric. With DSA you are supposed to be able to swap your Ethernet MAC driver (e.g.: mv643xx_eth, e1000e, igb, bcmsysport, bcmgenet, etc.) with any switch device (mv88e6xxx, b53, qca8k, etc.) and things would still work largely the same (minus switch driver differences obviously). In that regard, DSA also provides you with a number of things "for free" to try to push the standard Linux device driver model further: integration with PHYLIB/PHYLINK, HWMON, ethtool, etc. etc. -- Florian ^ permalink raw reply [flat|nested] 25+ messages in thread
* [PATCH net-next 5/6] dt-bindings: net: Add DT bindings for Microsemi Felix Switch 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil ` (3 preceding siblings ...) 2019-06-21 15:38 ` [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver Claudiu Manoil 5 siblings, 0 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver DT bindings for the Felix ethernet switch, consisting of the VSC9959 switch core integrated as a PCIe endpoint device. Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- .../devicetree/bindings/net/mscc-felix.txt | 77 +++++++++++++++++++ 1 file changed, 77 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/mscc-felix.txt diff --git a/Documentation/devicetree/bindings/net/mscc-felix.txt b/Documentation/devicetree/bindings/net/mscc-felix.txt new file mode 100644 index 000000000000..c91c63ba524c --- /dev/null +++ b/Documentation/devicetree/bindings/net/mscc-felix.txt @@ -0,0 +1,77 @@ +Microsemi Felix network Switch +============================== + +The Felix switch device is the Microsemi VSC9959 gigabit ethernet +switch core integrated as a PCIe endpoint device. + +Required properties: +- compatible : Should be "mscc,felix-switch" +- reg : Specifies PCIe Device Number and Function + Number of the integrated endpoint device, + according to parent node bindings. +- ethernet-ports: A container of child nodes representing + switch ports. + +"ethernet-ports" container has the following required properties: +- #address-cells: Must be 1 +- #size-cells : Must be 0 + +A list of child nodes representing switch ports is expected. +Each child port node must have the following mandatory property: +- reg : port id (address) in the switch (0..N-1) + +Port nodes may also contain the following optional standardised +properties, described in corresponding binding documents: + +- phy-handle : Phandle to a PHY on a MDIO bus. See + Documentation/devicetree/bindings/net/ethernet.txt + +or, +- fixed-link : "fixed-link" node, for internal ports or external + fixed-link connections. See + Documentation/devicetree/bindings/net/fixed-link.txt + +Example: + + switch@0,5 { + compatible = "mscc,felix-switch" + reg = <0x000500 0 0 0 0>; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + /* external ports */ + switch_port0: port@0 { + reg = <0>; + phy-handle = <&phy0>; + }; + switch_port1: port@1 { + reg = <1>; + phy-handle = <&phy1>; + }; + switch_port2: port@2 { + reg = <2>; + phy-handle = <&phy2>; + }; + switch_port3: port@3 { + reg = <3>; + phy-handle = <&phy3>; + }; + /* internal to-cpu ports */ + port@4 { + reg = <4>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + port@5 { + reg = <5>; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil ` (4 preceding siblings ...) 2019-06-21 15:38 ` [PATCH net-next 5/6] dt-bindings: net: Add DT bindings for Microsemi Felix Switch Claudiu Manoil @ 2019-06-21 15:38 ` Claudiu Manoil 2019-06-22 20:57 ` Andrew Lunn 5 siblings, 1 reply; 25+ messages in thread From: Claudiu Manoil @ 2019-06-21 15:38 UTC (permalink / raw) To: David S . Miller Cc: Alexandre Belloni, Rob Herring, Allan Nielsen, alexandru.marginean, netdev, devicetree, linux-arm-kernel, linux-kernel, UNGLinuxDriver, Catalin Horghidan This supports a switch core ethernet device from Microsemi (VSC9959) that can be integrated on different SoCs as a PCIe endpoint device. The switchdev functionality is provided by the core Ocelot switch driver. In this regard, the current driver is an instance of Microsemi's Ocelot core driver. The patch adds the PCI device driver part and defines the register map for the Felix switch core, as it has some differences in register addresses and bitfield mappings compared to the Ocelot switch. Also some registers or bitfields present on Ocelot are not available on Felix. That's why this driver has its own register map instance. Other than that, the common registers and bitfields have the same functionality and share the same name. In a few cases, some h/w operations have to be done differently on Felix due to missing bitfields. This is the case for the switch core reset and init. Because for this operation Ocelot uses some bits that are not present on Felix, the later has to use a register from the global registers block (GCB) instead. Signed-off-by: Catalin Horghidan <catalin.horghidan@gmail.com> Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> --- drivers/net/ethernet/mscc/Kconfig | 8 + drivers/net/ethernet/mscc/Makefile | 9 +- drivers/net/ethernet/mscc/felix_board.c | 392 +++++++++++++++++++++ drivers/net/ethernet/mscc/felix_regs.c | 448 ++++++++++++++++++++++++ drivers/net/ethernet/mscc/ocelot.h | 7 + 5 files changed, 862 insertions(+), 2 deletions(-) create mode 100644 drivers/net/ethernet/mscc/felix_board.c create mode 100644 drivers/net/ethernet/mscc/felix_regs.c diff --git a/drivers/net/ethernet/mscc/Kconfig b/drivers/net/ethernet/mscc/Kconfig index bcec0587cf61..e5a7fa69307e 100644 --- a/drivers/net/ethernet/mscc/Kconfig +++ b/drivers/net/ethernet/mscc/Kconfig @@ -29,4 +29,12 @@ config MSCC_OCELOT_SWITCH_OCELOT This driver supports the Ocelot network switch device as present on the Ocelot SoCs. +config MSCC_FELIX_SWITCH + tristate "Felix switch driver" + depends on MSCC_OCELOT_SWITCH + depends on PCI + help + This driver supports the Felix network switch device, connected as a + PCI device. + endif # NET_VENDOR_MICROSEMI diff --git a/drivers/net/ethernet/mscc/Makefile b/drivers/net/ethernet/mscc/Makefile index 9a36c26095c8..81593feb2ea1 100644 --- a/drivers/net/ethernet/mscc/Makefile +++ b/drivers/net/ethernet/mscc/Makefile @@ -1,5 +1,10 @@ # SPDX-License-Identifier: (GPL-2.0 OR MIT) obj-$(CONFIG_MSCC_OCELOT_SWITCH) += mscc_ocelot_common.o mscc_ocelot_common-y := ocelot.o ocelot_io.o -mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o ocelot_ace.o ocelot_flower.o -obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += ocelot_board.o +mscc_ocelot_common-y += ocelot_tc.o ocelot_police.o ocelot_ace.o ocelot_flower.o + +obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += mscc_ocelot.o +mscc_ocelot-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) := ocelot_regs.o ocelot_board.o + +obj-$(CONFIG_MSCC_FELIX_SWITCH) += mscc_felix.o +mscc_felix-$(CONFIG_MSCC_FELIX_SWITCH) := felix_regs.o felix_board.o diff --git a/drivers/net/ethernet/mscc/felix_board.c b/drivers/net/ethernet/mscc/felix_board.c new file mode 100644 index 000000000000..57f7a897b3ae --- /dev/null +++ b/drivers/net/ethernet/mscc/felix_board.c @@ -0,0 +1,392 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* Felix Switch driver + * + * Copyright 2018-2019 NXP + */ + +#include <linux/module.h> +#include <linux/pci.h> +#include <linux/netdevice.h> +#include <linux/phy_fixed.h> +#include <linux/phy.h> +#include <linux/of_mdio.h> +#include <linux/of_net.h> +#include <linux/iopoll.h> +#include <net/switchdev.h> +#include "ocelot.h" + +#define FELIX_DRV_VER_MAJ 1 +#define FELIX_DRV_VER_MIN 0 + +#define FELIX_DRV_STR "Felix Switch driver" +#define FELIX_DRV_VER_STR __stringify(FELIX_DRV_VER_MAJ) "." \ + __stringify(FELIX_DRV_VER_MIN) + +#define PCI_DEVICE_ID_FELIX 0xEEF0 + +/* Switch register block BAR */ +#define FELIX_SWITCH_BAR 4 + +static struct pci_device_id felix_ids[] = { + { PCI_DEVICE(PCI_VENDOR_ID_FREESCALE, PCI_DEVICE_ID_FELIX) }, + { 0, } +}; +MODULE_DEVICE_TABLE(pci, felix_ids); + +static struct { + enum ocelot_target id; + struct resource res; +} felix_io_res[] = { + { .id = ANA, + { + .start = 0x0280000, + .end = 0x028ffff, + .name = "ana", + } + }, + { .id = QS, + { + .start = 0x0080000, + .end = 0x00800ff, + .name = "qs", + } + }, + { .id = QSYS, + { + .start = 0x0200000, + .end = 0x021ffff, + .name = "qsys", + } + }, + { .id = REW, + { + .start = 0x0030000, + .end = 0x003ffff, + .name = "rew", + } + }, + { .id = SYS, + { + .start = 0x0010000, + .end = 0x001ffff, + .name = "sys", + } + }, + { .id = S2, + { + .start = 0x0060000, + .end = 0x00603ff, + .name = "s2", + } + }, + { .id = GCB, + { + .start = 0x0070000, + .end = 0x00701ff, + .name = "devcpu_gcb", + } + } +}; + +#define FELIX_MAX_NUM_PHY_PORTS 6 + +#define FELIX_PORT_RES_START 0x0100000 +#define FELIX_PORT_RES_SIZE 0x10000 + +static void __iomem *regs; + +static void felix_release_ports(struct ocelot *ocelot) +{ + struct ocelot_port *ocelot_port; + struct phy_device *phydev; + struct device_node *dn; + int i; + + for (i = 0; i < ocelot->num_phys_ports; i++) { + ocelot_port = ocelot->ports[i]; + if (!ocelot_port || !ocelot_port->phy || !ocelot_port->dev) + continue; + + phydev = ocelot_port->phy; + unregister_netdev(ocelot_port->dev); + free_netdev(ocelot_port->dev); + + if (phy_is_pseudo_fixed_link(phydev)) { + dn = phydev->mdio.dev.of_node; + /* decr refcnt: of_phy_register_fixed_link */ + of_phy_deregister_fixed_link(dn); + } + phy_device_free(phydev); /* decr refcnt: of_phy_find_device */ + } +} + +static int felix_ports_init(struct pci_dev *pdev) +{ + struct ocelot *ocelot = pci_get_drvdata(pdev); + struct device_node *np = ocelot->dev->of_node; + struct device_node *phy_node, *portnp; + struct phy_device *phydev; + void __iomem *port_regs; + resource_size_t base; + u32 port; + int err; + + ocelot->num_phys_ports = FELIX_MAX_NUM_PHY_PORTS; + + np = of_get_child_by_name(np, "ethernet-ports"); + if (!np) { + dev_err(&pdev->dev, "ethernet-ports sub-node not found\n"); + return -ENODEV; + } + + /* alloc netdev for each port */ + err = ocelot_init(ocelot); + if (err) + return err; + + base = pci_resource_start(pdev, FELIX_SWITCH_BAR); + for_each_available_child_of_node(np, portnp) { + struct resource res = {}; + int phy_mode; + + if (!portnp || !portnp->name || + of_node_cmp(portnp->name, "port") || + of_property_read_u32(portnp, "reg", &port)) + continue; + + if (port >= FELIX_MAX_NUM_PHY_PORTS) { + dev_err(ocelot->dev, "invalid port num: %d\n", port); + continue; + } + + res.start = base + FELIX_PORT_RES_START + + FELIX_PORT_RES_SIZE * port; + res.end = res.start + FELIX_PORT_RES_SIZE - 1; + res.flags = IORESOURCE_MEM; + res.name = "port"; + + port_regs = devm_ioremap_resource(ocelot->dev, &res); + if (IS_ERR(port_regs)) { + dev_err(ocelot->dev, + "failed to map registers for port %d\n", port); + continue; + } + + phy_node = of_parse_phandle(portnp, "phy-handle", 0); + if (!phy_node) { + if (!of_phy_is_fixed_link(portnp)) + continue; + + err = of_phy_register_fixed_link(portnp); + if (err < 0) { + dev_err(ocelot->dev, + "can't create fixed link for port:%d\n", + port); + continue; + } + phydev = of_phy_find_device(portnp); + } else { + phydev = of_phy_find_device(phy_node); + } + + of_node_put(phy_node); + + if (!phydev) + continue; + + phy_mode = of_get_phy_mode(portnp); + if (phy_mode < 0) + phy_mode = PHY_INTERFACE_MODE_NA; + + err = ocelot_probe_port(ocelot, port, port_regs, phydev); + if (err) { + dev_err(ocelot->dev, "failed to probe ports\n"); + goto release_ports; + } + + /* Felix configs */ + ocelot->ports[port]->phy_mode = phy_mode; + } + + return 0; + +release_ports: + felix_release_ports(ocelot); + + return err; +} + +#define FELIX_INIT_TIMEOUT 50000 +#define FELIX_GCB_RST_SLEEP 100 +#define FELIX_SYS_RAMINIT_SLEEP 80 + +static int felix_gcb_soft_rst_status(struct ocelot *ocelot) +{ + int val; + + regmap_field_read(ocelot->regfields[GCB_SOFT_RST_SWC_RST], &val); + return val; +} + +static int felix_sys_ram_init_status(struct ocelot *ocelot) +{ + return ocelot_read(ocelot, SYS_RAM_INIT); +} + +static int felix_init_switch_core(struct ocelot *ocelot) +{ + int val, err; + + /* soft-reset the switch core */ + regmap_field_write(ocelot->regfields[GCB_SOFT_RST_SWC_RST], 1); + + err = readx_poll_timeout(felix_gcb_soft_rst_status, ocelot, val, !val, + FELIX_GCB_RST_SLEEP, FELIX_INIT_TIMEOUT); + if (err) { + dev_err(ocelot->dev, "timeout: switch core reset\n"); + return err; + } + + /* initialize switch mem ~40us */ + ocelot_write(ocelot, SYS_RAM_INIT_RAM_INIT, SYS_RAM_INIT); + err = readx_poll_timeout(felix_sys_ram_init_status, ocelot, val, !val, + FELIX_SYS_RAMINIT_SLEEP, FELIX_INIT_TIMEOUT); + if (err) { + dev_err(ocelot->dev, "timeout: switch sram init\n"); + return err; + } + + /* enable switch core */ + regmap_field_write(ocelot->regfields[SYS_RESET_CFG_CORE_ENA], 1); + + return 0; +} + +static int felix_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) +{ + struct ocelot *ocelot; + resource_size_t base; + size_t len; + int i, err; + + err = pci_enable_device(pdev); + if (err) { + dev_err(&pdev->dev, "device enable failed\n"); + return err; + } + + /* set up for high or low dma */ + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64)); + if (err) { + err = dma_set_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(32)); + if (err) { + dev_err(&pdev->dev, + "DMA configuration failed: 0x%x\n", err); + goto err_dma; + } + } + + base = pci_resource_start(pdev, FELIX_SWITCH_BAR); + + pci_set_master(pdev); + + ocelot = devm_kzalloc(&pdev->dev, sizeof(*ocelot), GFP_KERNEL); + if (!ocelot) { + err = -ENOMEM; + goto err_alloc_ocelot; + } + + pci_set_drvdata(pdev, ocelot); + ocelot->dev = &pdev->dev; + + len = pci_resource_len(pdev, FELIX_SWITCH_BAR); + if (!len) { + err = -EINVAL; + goto err_resource_len; + } + + regs = pci_iomap(pdev, FELIX_SWITCH_BAR, len); + if (!regs) { + err = -ENXIO; + dev_err(&pdev->dev, "ioremap() failed\n"); + goto err_iomap; + } + + for (i = 0; i < ARRAY_SIZE(felix_io_res); i++) { + struct resource *res = &felix_io_res[i].res; + struct regmap *target; + + res->flags = IORESOURCE_MEM; + res->start += base; + res->end += base; + + target = ocelot_io_init(ocelot, res); + if (IS_ERR(target)) { + err = PTR_ERR(target); + goto err_iomap; + } + + ocelot->targets[felix_io_res[i].id] = target; + } + + err = felix_chip_init(ocelot); + if (err) + goto err_chip_init; + + err = felix_init_switch_core(ocelot); + if (err) + goto err_sw_core_init; + + err = felix_ports_init(pdev); + if (err) + goto err_ports_init; + + register_netdevice_notifier(&ocelot_netdevice_nb); + register_switchdev_notifier(&ocelot_switchdev_nb); + register_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb); + + dev_info(&pdev->dev, "%s v%s\n", FELIX_DRV_STR, FELIX_DRV_VER_STR); + return 0; + +err_ports_init: +err_chip_init: +err_sw_core_init: + pci_iounmap(pdev, regs); +err_iomap: +err_resource_len: +err_alloc_ocelot: +err_dma: + pci_disable_device(pdev); + + return err; +} + +static void felix_pci_remove(struct pci_dev *pdev) +{ + struct ocelot *ocelot; + + ocelot = pci_get_drvdata(pdev); + + /* stop workqueue thread */ + ocelot_deinit(ocelot); + unregister_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb); + unregister_switchdev_notifier(&ocelot_switchdev_nb); + unregister_netdevice_notifier(&ocelot_netdevice_nb); + + felix_release_ports(ocelot); + + pci_iounmap(pdev, regs); + pci_disable_device(pdev); +} + +static struct pci_driver felix_pci_driver = { + .name = KBUILD_MODNAME, + .id_table = felix_ids, + .probe = felix_pci_probe, + .remove = felix_pci_remove, +}; + +module_pci_driver(felix_pci_driver); + +MODULE_DESCRIPTION(FELIX_DRV_STR); +MODULE_LICENSE("Dual MIT/GPL"); diff --git a/drivers/net/ethernet/mscc/felix_regs.c b/drivers/net/ethernet/mscc/felix_regs.c new file mode 100644 index 000000000000..33e545505b4e --- /dev/null +++ b/drivers/net/ethernet/mscc/felix_regs.c @@ -0,0 +1,448 @@ +// SPDX-License-Identifier: (GPL-2.0 OR MIT) +/* Felix Switch driver + * + * Copyright 2017 Microsemi Corporation + * Copyright 2018-2019 NXP + */ +#include "ocelot.h" + +static const u32 felix_ana_regmap[] = { + REG(ANA_ADVLEARN, 0x0089a0), + REG(ANA_VLANMASK, 0x0089a4), + REG_RESERVED(ANA_PORT_B_DOMAIN), + REG(ANA_ANAGEFIL, 0x0089ac), + REG(ANA_ANEVENTS, 0x0089b0), + REG(ANA_STORMLIMIT_BURST, 0x0089b4), + REG(ANA_STORMLIMIT_CFG, 0x0089b8), + REG(ANA_ISOLATED_PORTS, 0x0089c8), + REG(ANA_COMMUNITY_PORTS, 0x0089cc), + REG(ANA_AUTOAGE, 0x0089d0), + REG(ANA_MACTOPTIONS, 0x0089d4), + REG(ANA_LEARNDISC, 0x0089d8), + REG(ANA_AGENCTRL, 0x0089dc), + REG(ANA_MIRRORPORTS, 0x0089e0), + REG(ANA_EMIRRORPORTS, 0x0089e4), + REG(ANA_FLOODING, 0x0089e8), + REG(ANA_FLOODING_IPMC, 0x008a08), + REG(ANA_SFLOW_CFG, 0x008a0c), + REG(ANA_PORT_MODE, 0x008a28), + REG(ANA_CUT_THRU_CFG, 0x008a48), + REG(ANA_PGID_PGID, 0x008400), + REG(ANA_TABLES_ANMOVED, 0x007f1c), + REG(ANA_TABLES_MACHDATA, 0x007f20), + REG(ANA_TABLES_MACLDATA, 0x007f24), + REG(ANA_TABLES_STREAMDATA, 0x007f28), + REG(ANA_TABLES_MACACCESS, 0x007f2c), + REG(ANA_TABLES_MACTINDX, 0x007f30), + REG(ANA_TABLES_VLANACCESS, 0x007f34), + REG(ANA_TABLES_VLANTIDX, 0x007f38), + REG(ANA_TABLES_ISDXACCESS, 0x007f3c), + REG(ANA_TABLES_ISDXTIDX, 0x007f40), + REG(ANA_TABLES_ENTRYLIM, 0x007f00), + REG(ANA_TABLES_PTP_ID_HIGH, 0x007f44), + REG(ANA_TABLES_PTP_ID_LOW, 0x007f48), + REG(ANA_TABLES_STREAMACCESS, 0x007f4c), + REG(ANA_TABLES_STREAMTIDX, 0x007f50), + REG(ANA_TABLES_SEQ_HISTORY, 0x007f54), + REG(ANA_TABLES_SEQ_MASK, 0x007f58), + REG(ANA_TABLES_SFID_MASK, 0x007f5c), + REG(ANA_TABLES_SFIDACCESS, 0x007f60), + REG(ANA_TABLES_SFIDTIDX, 0x007f64), + REG(ANA_MSTI_STATE, 0x008600), + REG(ANA_OAM_UPM_LM_CNT, 0x008000), + REG(ANA_SG_ACCESS_CTRL, 0x008a64), + REG(ANA_SG_CONFIG_REG_1, 0x007fb0), + REG(ANA_SG_CONFIG_REG_2, 0x007fb4), + REG(ANA_SG_CONFIG_REG_3, 0x007fb8), + REG(ANA_SG_CONFIG_REG_4, 0x007fbc), + REG(ANA_SG_CONFIG_REG_5, 0x007fc0), + REG(ANA_SG_GCL_GS_CONFIG, 0x007f80), + REG(ANA_SG_GCL_TI_CONFIG, 0x007f90), + REG(ANA_SG_STATUS_REG_1, 0x008980), + REG(ANA_SG_STATUS_REG_2, 0x008984), + REG(ANA_SG_STATUS_REG_3, 0x008988), + REG(ANA_PORT_VLAN_CFG, 0x007800), + REG(ANA_PORT_DROP_CFG, 0x007804), + REG(ANA_PORT_QOS_CFG, 0x007808), + REG(ANA_PORT_VCAP_CFG, 0x00780c), + REG(ANA_PORT_VCAP_S1_KEY_CFG, 0x007810), + REG(ANA_PORT_VCAP_S2_CFG, 0x00781c), + REG(ANA_PORT_PCP_DEI_MAP, 0x007820), + REG(ANA_PORT_CPU_FWD_CFG, 0x007860), + REG(ANA_PORT_CPU_FWD_BPDU_CFG, 0x007864), + REG(ANA_PORT_CPU_FWD_GARP_CFG, 0x007868), + REG(ANA_PORT_CPU_FWD_CCM_CFG, 0x00786c), + REG(ANA_PORT_PORT_CFG, 0x007870), + REG(ANA_PORT_POL_CFG, 0x007874), + REG(ANA_PORT_PTP_CFG, 0x007878), + REG(ANA_PORT_PTP_DLY1_CFG, 0x00787c), + REG(ANA_PORT_PTP_DLY2_CFG, 0x007880), + REG(ANA_PORT_SFID_CFG, 0x007884), + REG(ANA_PFC_PFC_CFG, 0x008800), + REG_RESERVED(ANA_PFC_PFC_TIMER), + REG_RESERVED(ANA_IPT_OAM_MEP_CFG), + REG_RESERVED(ANA_IPT_IPT), + REG_RESERVED(ANA_PPT_PPT), + REG_RESERVED(ANA_FID_MAP_FID_MAP), + REG(ANA_AGGR_CFG, 0x008a68), + REG(ANA_CPUQ_CFG, 0x008a6c), + REG_RESERVED(ANA_CPUQ_CFG2), + REG(ANA_CPUQ_8021_CFG, 0x008a74), + REG(ANA_DSCP_CFG, 0x008ab4), + REG(ANA_DSCP_REWR_CFG, 0x008bb4), + REG(ANA_VCAP_RNG_TYPE_CFG, 0x008bf4), + REG(ANA_VCAP_RNG_VAL_CFG, 0x008c14), + REG_RESERVED(ANA_VRAP_CFG), + REG_RESERVED(ANA_VRAP_HDR_DATA), + REG_RESERVED(ANA_VRAP_HDR_MASK), + REG(ANA_DISCARD_CFG, 0x008c40), + REG(ANA_FID_CFG, 0x008c44), + REG(ANA_POL_PIR_CFG, 0x004000), + REG(ANA_POL_CIR_CFG, 0x004004), + REG(ANA_POL_MODE_CFG, 0x004008), + REG(ANA_POL_PIR_STATE, 0x00400c), + REG(ANA_POL_CIR_STATE, 0x004010), + REG_RESERVED(ANA_POL_STATE), + REG(ANA_POL_FLOWC, 0x008c48), + REG(ANA_POL_HYST, 0x008cb4), + REG_RESERVED(ANA_POL_MISC_CFG), +}; + +static const u32 felix_qs_regmap[] = { + REG(QS_XTR_GRP_CFG, 0x000000), + REG(QS_XTR_RD, 0x000008), + REG(QS_XTR_FRM_PRUNING, 0x000010), + REG(QS_XTR_FLUSH, 0x000018), + REG(QS_XTR_DATA_PRESENT, 0x00001c), + REG(QS_XTR_CFG, 0x000020), + REG(QS_INJ_GRP_CFG, 0x000024), + REG(QS_INJ_WR, 0x00002c), + REG(QS_INJ_CTRL, 0x000034), + REG(QS_INJ_STATUS, 0x00003c), + REG(QS_INJ_ERR, 0x000040), + REG_RESERVED(QS_INH_DBG), +}; + +static const u32 felix_s2_regmap[] = { + REG(S2_CORE_UPDATE_CTRL, 0x000000), + REG(S2_CORE_MV_CFG, 0x000004), + REG(S2_CACHE_ENTRY_DAT, 0x000008), + REG(S2_CACHE_MASK_DAT, 0x000108), + REG(S2_CACHE_ACTION_DAT, 0x000208), + REG(S2_CACHE_CNT_DAT, 0x000308), + REG(S2_CACHE_TG_DAT, 0x000388), +}; + +static const u32 felix_qsys_regmap[] = { + REG(QSYS_PORT_MODE, 0x00f460), + REG(QSYS_SWITCH_PORT_MODE, 0x00f480), + REG(QSYS_STAT_CNT_CFG, 0x00f49c), + REG(QSYS_EEE_CFG, 0x00f4a0), + REG(QSYS_EEE_THRES, 0x00f4b8), + REG(QSYS_IGR_NO_SHARING, 0x00f4bc), + REG(QSYS_EGR_NO_SHARING, 0x00f4c0), + REG(QSYS_SW_STATUS, 0x00f4c4), + REG(QSYS_EXT_CPU_CFG, 0x00f4e0), + REG_RESERVED(QSYS_PAD_CFG), + REG(QSYS_CPU_GROUP_MAP, 0x00f4e8), + REG_RESERVED(QSYS_QMAP), + REG_RESERVED(QSYS_ISDX_SGRP), + REG_RESERVED(QSYS_TIMED_FRAME_ENTRY), + REG(QSYS_TFRM_MISC, 0x00f50c), + REG(QSYS_TFRM_PORT_DLY, 0x00f510), + REG(QSYS_TFRM_TIMER_CFG_1, 0x00f514), + REG(QSYS_TFRM_TIMER_CFG_2, 0x00f518), + REG(QSYS_TFRM_TIMER_CFG_3, 0x00f51c), + REG(QSYS_TFRM_TIMER_CFG_4, 0x00f520), + REG(QSYS_TFRM_TIMER_CFG_5, 0x00f524), + REG(QSYS_TFRM_TIMER_CFG_6, 0x00f528), + REG(QSYS_TFRM_TIMER_CFG_7, 0x00f52c), + REG(QSYS_TFRM_TIMER_CFG_8, 0x00f530), + REG(QSYS_RED_PROFILE, 0x00f534), + REG(QSYS_RES_QOS_MODE, 0x00f574), + REG(QSYS_RES_CFG, 0x00c000), + REG(QSYS_RES_STAT, 0x00c004), + REG(QSYS_EGR_DROP_MODE, 0x00f578), + REG(QSYS_EQ_CTRL, 0x00f57c), + REG_RESERVED(QSYS_EVENTS_CORE), + REG(QSYS_QMAXSDU_CFG_0, 0x00f584), + REG(QSYS_QMAXSDU_CFG_1, 0x00f5a0), + REG(QSYS_QMAXSDU_CFG_2, 0x00f5bc), + REG(QSYS_QMAXSDU_CFG_3, 0x00f5d8), + REG(QSYS_QMAXSDU_CFG_4, 0x00f5f4), + REG(QSYS_QMAXSDU_CFG_5, 0x00f610), + REG(QSYS_QMAXSDU_CFG_6, 0x00f62c), + REG(QSYS_QMAXSDU_CFG_7, 0x00f648), + REG(QSYS_PREEMPTION_CFG, 0x00f664), + REG_RESERVED(QSYS_CIR_CFG), + REG(QSYS_EIR_CFG, 0x000004), + REG(QSYS_SE_CFG, 0x000008), + REG(QSYS_SE_DWRR_CFG, 0x00000c), + REG_RESERVED(QSYS_SE_CONNECT), + REG(QSYS_SE_DLB_SENSE, 0x000040), + REG(QSYS_CIR_STATE, 0x000044), + REG(QSYS_EIR_STATE, 0x000048), + REG_RESERVED(QSYS_SE_STATE), + REG(QSYS_HSCH_MISC_CFG, 0x00f67c), + REG(QSYS_TAG_CONFIG, 0x00f680), + REG(QSYS_TAS_PARAM_CFG_CTRL, 0x00f698), + REG(QSYS_PORT_MAX_SDU, 0x00f69c), + REG(QSYS_PARAM_CFG_REG_1, 0x00f440), + REG(QSYS_PARAM_CFG_REG_2, 0x00f444), + REG(QSYS_PARAM_CFG_REG_3, 0x00f448), + REG(QSYS_PARAM_CFG_REG_4, 0x00f44c), + REG(QSYS_PARAM_CFG_REG_5, 0x00f450), + REG(QSYS_GCL_CFG_REG_1, 0x00f454), + REG(QSYS_GCL_CFG_REG_2, 0x00f458), + REG(QSYS_PARAM_STATUS_REG_1, 0x00f400), + REG(QSYS_PARAM_STATUS_REG_2, 0x00f404), + REG(QSYS_PARAM_STATUS_REG_3, 0x00f408), + REG(QSYS_PARAM_STATUS_REG_4, 0x00f40c), + REG(QSYS_PARAM_STATUS_REG_5, 0x00f410), + REG(QSYS_PARAM_STATUS_REG_6, 0x00f414), + REG(QSYS_PARAM_STATUS_REG_7, 0x00f418), + REG(QSYS_PARAM_STATUS_REG_8, 0x00f41c), + REG(QSYS_PARAM_STATUS_REG_9, 0x00f420), + REG(QSYS_GCL_STATUS_REG_1, 0x00f424), + REG(QSYS_GCL_STATUS_REG_2, 0x00f428), +}; + +static const u32 felix_rew_regmap[] = { + REG(REW_PORT_VLAN_CFG, 0x000000), + REG(REW_TAG_CFG, 0x000004), + REG(REW_PORT_CFG, 0x000008), + REG(REW_DSCP_CFG, 0x00000c), + REG(REW_PCP_DEI_QOS_MAP_CFG, 0x000010), + REG(REW_PTP_CFG, 0x000050), + REG(REW_PTP_DLY1_CFG, 0x000054), + REG(REW_RED_TAG_CFG, 0x000058), + REG(REW_DSCP_REMAP_DP1_CFG, 0x000410), + REG(REW_DSCP_REMAP_CFG, 0x000510), + REG_RESERVED(REW_STAT_CFG), + REG_RESERVED(REW_REW_STICKY), + REG_RESERVED(REW_PPT), +}; + +static const u32 felix_sys_regmap[] = { + REG(SYS_COUNT_RX_OCTETS, 0x000000), + REG(SYS_COUNT_RX_MULTICAST, 0x000008), + REG(SYS_COUNT_RX_SHORTS, 0x000010), + REG(SYS_COUNT_RX_FRAGMENTS, 0x000014), + REG(SYS_COUNT_RX_JABBERS, 0x000018), + REG(SYS_COUNT_RX_64, 0x000024), + REG(SYS_COUNT_RX_65_127, 0x000028), + REG(SYS_COUNT_RX_128_255, 0x00002c), + REG(SYS_COUNT_RX_256_1023, 0x000030), + REG(SYS_COUNT_RX_1024_1526, 0x000034), + REG(SYS_COUNT_RX_1527_MAX, 0x000038), + REG(SYS_COUNT_RX_LONGS, 0x000044), + REG(SYS_COUNT_TX_OCTETS, 0x000200), + REG(SYS_COUNT_TX_COLLISION, 0x000210), + REG(SYS_COUNT_TX_DROPS, 0x000214), + REG(SYS_COUNT_TX_64, 0x00021c), + REG(SYS_COUNT_TX_65_127, 0x000220), + REG(SYS_COUNT_TX_128_511, 0x000224), + REG(SYS_COUNT_TX_512_1023, 0x000228), + REG(SYS_COUNT_TX_1024_1526, 0x00022c), + REG(SYS_COUNT_TX_1527_MAX, 0x000230), + REG(SYS_COUNT_TX_AGING, 0x000278), + REG(SYS_RESET_CFG, 0x000e00), + REG(SYS_SR_ETYPE_CFG, 0x000e04), + REG(SYS_VLAN_ETYPE_CFG, 0x000e08), + REG(SYS_PORT_MODE, 0x000e0c), + REG(SYS_FRONT_PORT_MODE, 0x000e2c), + REG(SYS_FRM_AGING, 0x000e44), + REG(SYS_STAT_CFG, 0x000e48), + REG(SYS_SW_STATUS, 0x000e4c), + REG_RESERVED(SYS_MISC_CFG), + REG(SYS_REW_MAC_HIGH_CFG, 0x000e6c), + REG(SYS_REW_MAC_LOW_CFG, 0x000e84), + REG(SYS_TIMESTAMP_OFFSET, 0x000e9c), + REG(SYS_PAUSE_CFG, 0x000ea0), + REG(SYS_PAUSE_TOT_CFG, 0x000ebc), + REG(SYS_ATOP, 0x000ec0), + REG(SYS_ATOP_TOT_CFG, 0x000edc), + REG(SYS_MAC_FC_CFG, 0x000ee0), + REG(SYS_MMGT, 0x000ef8), + REG_RESERVED(SYS_MMGT_FAST), + REG_RESERVED(SYS_EVENTS_DIF), + REG_RESERVED(SYS_EVENTS_CORE), + REG_RESERVED(SYS_CNT), + REG(SYS_PTP_STATUS, 0x000f14), + REG(SYS_PTP_TXSTAMP, 0x000f18), + REG(SYS_PTP_NXT, 0x000f1c), + REG(SYS_PTP_CFG, 0x000f20), + REG(SYS_RAM_INIT, 0x000f24), + REG_RESERVED(SYS_CM_ADDR), + REG_RESERVED(SYS_CM_DATA_WR), + REG_RESERVED(SYS_CM_DATA_RD), + REG_RESERVED(SYS_CM_OP), + REG_RESERVED(SYS_CM_DATA), +}; + +static const u32 felix_gcb_regmap[] = { + REG(GCB_SOFT_RST, 0x000004), +}; + +static const u32 *felix_regmap[] = { + [ANA] = felix_ana_regmap, + [QS] = felix_qs_regmap, + [QSYS] = felix_qsys_regmap, + [REW] = felix_rew_regmap, + [SYS] = felix_sys_regmap, + [S2] = felix_s2_regmap, + [GCB] = felix_gcb_regmap, +}; + +static const struct reg_field felix_regfields[REGFIELD_MAX] = { + [ANA_ADVLEARN_VLAN_CHK] = REG_FIELD(ANA_ADVLEARN, 6, 6), + [ANA_ADVLEARN_LEARN_MIRROR] = REG_FIELD(ANA_ADVLEARN, 0, 5), + [ANA_ANEVENTS_FLOOD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 30, 30), + [ANA_ANEVENTS_AUTOAGE] = REG_FIELD(ANA_ANEVENTS, 26, 26), + [ANA_ANEVENTS_STORM_DROP] = REG_FIELD(ANA_ANEVENTS, 24, 24), + [ANA_ANEVENTS_LEARN_DROP] = REG_FIELD(ANA_ANEVENTS, 23, 23), + [ANA_ANEVENTS_AGED_ENTRY] = REG_FIELD(ANA_ANEVENTS, 22, 22), + [ANA_ANEVENTS_CPU_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 21, 21), + [ANA_ANEVENTS_AUTO_LEARN_FAILED] = REG_FIELD(ANA_ANEVENTS, 20, 20), + [ANA_ANEVENTS_LEARN_REMOVE] = REG_FIELD(ANA_ANEVENTS, 19, 19), + [ANA_ANEVENTS_AUTO_LEARNED] = REG_FIELD(ANA_ANEVENTS, 18, 18), + [ANA_ANEVENTS_AUTO_MOVED] = REG_FIELD(ANA_ANEVENTS, 17, 17), + [ANA_ANEVENTS_CLASSIFIED_DROP] = REG_FIELD(ANA_ANEVENTS, 15, 15), + [ANA_ANEVENTS_CLASSIFIED_COPY] = REG_FIELD(ANA_ANEVENTS, 14, 14), + [ANA_ANEVENTS_VLAN_DISCARD] = REG_FIELD(ANA_ANEVENTS, 13, 13), + [ANA_ANEVENTS_FWD_DISCARD] = REG_FIELD(ANA_ANEVENTS, 12, 12), + [ANA_ANEVENTS_MULTICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 11, 11), + [ANA_ANEVENTS_UNICAST_FLOOD] = REG_FIELD(ANA_ANEVENTS, 10, 10), + [ANA_ANEVENTS_DEST_KNOWN] = REG_FIELD(ANA_ANEVENTS, 9, 9), + [ANA_ANEVENTS_BUCKET3_MATCH] = REG_FIELD(ANA_ANEVENTS, 8, 8), + [ANA_ANEVENTS_BUCKET2_MATCH] = REG_FIELD(ANA_ANEVENTS, 7, 7), + [ANA_ANEVENTS_BUCKET1_MATCH] = REG_FIELD(ANA_ANEVENTS, 6, 6), + [ANA_ANEVENTS_BUCKET0_MATCH] = REG_FIELD(ANA_ANEVENTS, 5, 5), + [ANA_ANEVENTS_CPU_OPERATION] = REG_FIELD(ANA_ANEVENTS, 4, 4), + [ANA_ANEVENTS_DMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 3, 3), + [ANA_ANEVENTS_SMAC_LOOKUP] = REG_FIELD(ANA_ANEVENTS, 2, 2), + [ANA_ANEVENTS_SEQ_GEN_ERR_0] = REG_FIELD(ANA_ANEVENTS, 1, 1), + [ANA_ANEVENTS_SEQ_GEN_ERR_1] = REG_FIELD(ANA_ANEVENTS, 0, 0), + [ANA_TABLES_MACACCESS_B_DOM] = REG_FIELD(ANA_TABLES_MACACCESS, 16, 16), + [ANA_TABLES_MACTINDX_BUCKET] = REG_FIELD(ANA_TABLES_MACTINDX, 11, 12), + [ANA_TABLES_MACTINDX_M_INDEX] = REG_FIELD(ANA_TABLES_MACTINDX, 0, 10), + [SYS_RESET_CFG_CORE_ENA] = REG_FIELD(SYS_RESET_CFG, 0, 0), + [GCB_SOFT_RST_SWC_RST] = REG_FIELD(GCB_SOFT_RST, 0, 0), +}; + +static const struct ocelot_stat_layout felix_stats_layout[] = { + { .name = "rx_octets", .offset = 0x00, }, + { .name = "rx_unicast", .offset = 0x01, }, + { .name = "rx_multicast", .offset = 0x02, }, + { .name = "rx_broadcast", .offset = 0x03, }, + { .name = "rx_shorts", .offset = 0x04, }, + { .name = "rx_fragments", .offset = 0x05, }, + { .name = "rx_jabbers", .offset = 0x06, }, + { .name = "rx_crc_align_errs", .offset = 0x07, }, + { .name = "rx_sym_errs", .offset = 0x08, }, + { .name = "rx_frames_below_65_octets", .offset = 0x09, }, + { .name = "rx_frames_65_to_127_octets", .offset = 0x0A, }, + { .name = "rx_frames_128_to_255_octets", .offset = 0x0B, }, + { .name = "rx_frames_256_to_511_octets", .offset = 0x0C, }, + { .name = "rx_frames_512_to_1023_octets", .offset = 0x0D, }, + { .name = "rx_frames_1024_to_1526_octets", .offset = 0x0E, }, + { .name = "rx_frames_over_1526_octets", .offset = 0x0F, }, + { .name = "rx_pause", .offset = 0x10, }, + { .name = "rx_control", .offset = 0x11, }, + { .name = "rx_longs", .offset = 0x12, }, + { .name = "rx_classified_drops", .offset = 0x13, }, + { .name = "rx_red_prio_0", .offset = 0x14, }, + { .name = "rx_red_prio_1", .offset = 0x15, }, + { .name = "rx_red_prio_2", .offset = 0x16, }, + { .name = "rx_red_prio_3", .offset = 0x17, }, + { .name = "rx_red_prio_4", .offset = 0x18, }, + { .name = "rx_red_prio_5", .offset = 0x19, }, + { .name = "rx_red_prio_6", .offset = 0x1A, }, + { .name = "rx_red_prio_7", .offset = 0x1B, }, + { .name = "rx_yellow_prio_0", .offset = 0x1C, }, + { .name = "rx_yellow_prio_1", .offset = 0x1D, }, + { .name = "rx_yellow_prio_2", .offset = 0x1E, }, + { .name = "rx_yellow_prio_3", .offset = 0x1F, }, + { .name = "rx_yellow_prio_4", .offset = 0x20, }, + { .name = "rx_yellow_prio_5", .offset = 0x21, }, + { .name = "rx_yellow_prio_6", .offset = 0x22, }, + { .name = "rx_yellow_prio_7", .offset = 0x23, }, + { .name = "rx_green_prio_0", .offset = 0x24, }, + { .name = "rx_green_prio_1", .offset = 0x25, }, + { .name = "rx_green_prio_2", .offset = 0x26, }, + { .name = "rx_green_prio_3", .offset = 0x27, }, + { .name = "rx_green_prio_4", .offset = 0x28, }, + { .name = "rx_green_prio_5", .offset = 0x29, }, + { .name = "rx_green_prio_6", .offset = 0x2A, }, + { .name = "rx_green_prio_7", .offset = 0x2B, }, + { .name = "tx_octets", .offset = 0x80, }, + { .name = "tx_unicast", .offset = 0x81, }, + { .name = "tx_multicast", .offset = 0x82, }, + { .name = "tx_broadcast", .offset = 0x83, }, + { .name = "tx_collision", .offset = 0x84, }, + { .name = "tx_drops", .offset = 0x85, }, + { .name = "tx_pause", .offset = 0x86, }, + { .name = "tx_frames_below_65_octets", .offset = 0x87, }, + { .name = "tx_frames_65_to_127_octets", .offset = 0x88, }, + { .name = "tx_frames_128_255_octets", .offset = 0x89, }, + { .name = "tx_frames_256_511_octets", .offset = 0x8A, }, + { .name = "tx_frames_512_1023_octets", .offset = 0x8B, }, + { .name = "tx_frames_1024_1526_octets", .offset = 0x8C, }, + { .name = "tx_frames_over_1526_octets", .offset = 0x8D, }, + { .name = "tx_yellow_prio_0", .offset = 0x8E, }, + { .name = "tx_yellow_prio_1", .offset = 0x8F, }, + { .name = "tx_yellow_prio_2", .offset = 0x90, }, + { .name = "tx_yellow_prio_3", .offset = 0x91, }, + { .name = "tx_yellow_prio_4", .offset = 0x92, }, + { .name = "tx_yellow_prio_5", .offset = 0x93, }, + { .name = "tx_yellow_prio_6", .offset = 0x94, }, + { .name = "tx_yellow_prio_7", .offset = 0x95, }, + { .name = "tx_green_prio_0", .offset = 0x96, }, + { .name = "tx_green_prio_1", .offset = 0x97, }, + { .name = "tx_green_prio_2", .offset = 0x98, }, + { .name = "tx_green_prio_3", .offset = 0x99, }, + { .name = "tx_green_prio_4", .offset = 0x9A, }, + { .name = "tx_green_prio_5", .offset = 0x9B, }, + { .name = "tx_green_prio_6", .offset = 0x9C, }, + { .name = "tx_green_prio_7", .offset = 0x9D, }, + { .name = "tx_aged", .offset = 0x9E, }, + { .name = "drop_local", .offset = 0x100, }, + { .name = "drop_tail", .offset = 0x101, }, + { .name = "drop_yellow_prio_0", .offset = 0x102, }, + { .name = "drop_yellow_prio_1", .offset = 0x103, }, + { .name = "drop_yellow_prio_2", .offset = 0x104, }, + { .name = "drop_yellow_prio_3", .offset = 0x105, }, + { .name = "drop_yellow_prio_4", .offset = 0x106, }, + { .name = "drop_yellow_prio_5", .offset = 0x107, }, + { .name = "drop_yellow_prio_6", .offset = 0x108, }, + { .name = "drop_yellow_prio_7", .offset = 0x109, }, + { .name = "drop_green_prio_0", .offset = 0x10A, }, + { .name = "drop_green_prio_1", .offset = 0x10B, }, + { .name = "drop_green_prio_2", .offset = 0x10C, }, + { .name = "drop_green_prio_3", .offset = 0x10D, }, + { .name = "drop_green_prio_4", .offset = 0x10E, }, + { .name = "drop_green_prio_5", .offset = 0x10F, }, + { .name = "drop_green_prio_6", .offset = 0x110, }, + { .name = "drop_green_prio_7", .offset = 0x111, }, +}; + +int felix_chip_init(struct ocelot *ocelot) +{ + int ret; + + ocelot->map = felix_regmap; + ocelot->stats_layout = felix_stats_layout; + ocelot->num_stats = ARRAY_SIZE(felix_stats_layout); + ocelot->shared_queue_sz = 128 * 1024; + + ret = ocelot_regfields_init(ocelot, felix_regfields); + if (ret) { + dev_err(ocelot->dev, "failed to init reg fields map\n"); + return ret; + } + + eth_random_addr(ocelot->base_mac); + ocelot->base_mac[5] &= 0xf0; + return 0; +} +EXPORT_SYMBOL(felix_chip_init); diff --git a/drivers/net/ethernet/mscc/ocelot.h b/drivers/net/ethernet/mscc/ocelot.h index 4235d7294772..1d9e76584037 100644 --- a/drivers/net/ethernet/mscc/ocelot.h +++ b/drivers/net/ethernet/mscc/ocelot.h @@ -63,6 +63,9 @@ struct frame_info { #define REG_MASK GENMASK(TARGET_OFFSET - 1, 0) #define REG(reg, offset) [reg & REG_MASK] = offset +#define REG_RESERVED_ADDR 0xffffffff +#define REG_RESERVED(reg) REG(reg, REG_RESERVED_ADDR) + enum ocelot_target { ANA = 1, QS, @@ -70,6 +73,7 @@ enum ocelot_target { REW, SYS, S2, + GCB, HSIO, TARGET_MAX, }; @@ -343,6 +347,7 @@ enum ocelot_reg { S2_CACHE_ACTION_DAT, S2_CACHE_CNT_DAT, S2_CACHE_TG_DAT, + GCB_SOFT_RST = GCB << TARGET_OFFSET, }; enum ocelot_regfield { @@ -390,6 +395,7 @@ enum ocelot_regfield { SYS_RESET_CFG_CORE_ENA, SYS_RESET_CFG_MEM_ENA, SYS_RESET_CFG_MEM_INIT, + GCB_SOFT_RST_SWC_RST, REGFIELD_MAX }; @@ -501,6 +507,7 @@ struct regmap *ocelot_io_init(struct ocelot *ocelot, struct resource *res); int ocelot_init(struct ocelot *ocelot); void ocelot_deinit(struct ocelot *ocelot); int ocelot_chip_init(struct ocelot *ocelot); +int felix_chip_init(struct ocelot *ocelot); int ocelot_probe_port(struct ocelot *ocelot, u8 port, void __iomem *regs, struct phy_device *phy); -- 2.17.1 ^ permalink raw reply related [flat|nested] 25+ messages in thread
* Re: [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver 2019-06-21 15:38 ` [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver Claudiu Manoil @ 2019-06-22 20:57 ` Andrew Lunn 2019-06-24 13:19 ` Claudiu Manoil 0 siblings, 1 reply; 25+ messages in thread From: Andrew Lunn @ 2019-06-22 20:57 UTC (permalink / raw) To: Claudiu Manoil Cc: David S . Miller, devicetree, Alexandre Belloni, netdev, alexandru.marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, Catalin Horghidan, linux-arm-kernel On Fri, Jun 21, 2019 at 06:38:52PM +0300, Claudiu Manoil wrote: > This supports a switch core ethernet device from Microsemi > (VSC9959) that can be integrated on different SoCs as a PCIe > endpoint device. > > The switchdev functionality is provided by the core Ocelot > switch driver. In this regard, the current driver is an > instance of Microsemi's Ocelot core driver. > > The patch adds the PCI device driver part and defines the > register map for the Felix switch core, as it has some > differences in register addresses and bitfield mappings > compared to the Ocelot switch. Also some registers or > bitfields present on Ocelot are not available on Felix. > That's why this driver has its own register map instance. > Other than that, the common registers and bitfields have the > same functionality and share the same name. > > In a few cases, some h/w operations have to be done differently > on Felix due to missing bitfields. This is the case for the > switch core reset and init. Because for this operation Ocelot > uses some bits that are not present on Felix, the later has to > use a register from the global registers block (GCB) instead. > > Signed-off-by: Catalin Horghidan <catalin.horghidan@gmail.com> > Signed-off-by: Claudiu Manoil <claudiu.manoil@nxp.com> > --- > drivers/net/ethernet/mscc/Kconfig | 8 + > drivers/net/ethernet/mscc/Makefile | 9 +- > drivers/net/ethernet/mscc/felix_board.c | 392 +++++++++++++++++++++ > drivers/net/ethernet/mscc/felix_regs.c | 448 ++++++++++++++++++++++++ > drivers/net/ethernet/mscc/ocelot.h | 7 + > 5 files changed, 862 insertions(+), 2 deletions(-) > create mode 100644 drivers/net/ethernet/mscc/felix_board.c > create mode 100644 drivers/net/ethernet/mscc/felix_regs.c > > diff --git a/drivers/net/ethernet/mscc/Kconfig b/drivers/net/ethernet/mscc/Kconfig > index bcec0587cf61..e5a7fa69307e 100644 > --- a/drivers/net/ethernet/mscc/Kconfig > +++ b/drivers/net/ethernet/mscc/Kconfig > @@ -29,4 +29,12 @@ config MSCC_OCELOT_SWITCH_OCELOT > This driver supports the Ocelot network switch device as present on > the Ocelot SoCs. > > +config MSCC_FELIX_SWITCH > + tristate "Felix switch driver" > + depends on MSCC_OCELOT_SWITCH > + depends on PCI > + help > + This driver supports the Felix network switch device, connected as a > + PCI device. > + > endif # NET_VENDOR_MICROSEMI > diff --git a/drivers/net/ethernet/mscc/Makefile b/drivers/net/ethernet/mscc/Makefile > index 9a36c26095c8..81593feb2ea1 100644 > --- a/drivers/net/ethernet/mscc/Makefile > +++ b/drivers/net/ethernet/mscc/Makefile > @@ -1,5 +1,10 @@ > # SPDX-License-Identifier: (GPL-2.0 OR MIT) > obj-$(CONFIG_MSCC_OCELOT_SWITCH) += mscc_ocelot_common.o > mscc_ocelot_common-y := ocelot.o ocelot_io.o > -mscc_ocelot_common-y += ocelot_regs.o ocelot_tc.o ocelot_police.o ocelot_ace.o ocelot_flower.o > -obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += ocelot_board.o > +mscc_ocelot_common-y += ocelot_tc.o ocelot_police.o ocelot_ace.o ocelot_flower.o > + > +obj-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) += mscc_ocelot.o > +mscc_ocelot-$(CONFIG_MSCC_OCELOT_SWITCH_OCELOT) := ocelot_regs.o ocelot_board.o > + > +obj-$(CONFIG_MSCC_FELIX_SWITCH) += mscc_felix.o > +mscc_felix-$(CONFIG_MSCC_FELIX_SWITCH) := felix_regs.o felix_board.o > diff --git a/drivers/net/ethernet/mscc/felix_board.c b/drivers/net/ethernet/mscc/felix_board.c > new file mode 100644 > index 000000000000..57f7a897b3ae > --- /dev/null > +++ b/drivers/net/ethernet/mscc/felix_board.c > @@ -0,0 +1,392 @@ > +// SPDX-License-Identifier: (GPL-2.0 OR MIT) > +/* Felix Switch driver > + * > + * Copyright 2018-2019 NXP > + */ > + > +#include <linux/module.h> > +#include <linux/pci.h> > +#include <linux/netdevice.h> > +#include <linux/phy_fixed.h> > +#include <linux/phy.h> > +#include <linux/of_mdio.h> > +#include <linux/of_net.h> > +#include <linux/iopoll.h> > +#include <net/switchdev.h> > +#include "ocelot.h" > + > +#define FELIX_DRV_VER_MAJ 1 > +#define FELIX_DRV_VER_MIN 0 > + > +#define FELIX_DRV_STR "Felix Switch driver" > +#define FELIX_DRV_VER_STR __stringify(FELIX_DRV_VER_MAJ) "." \ > + __stringify(FELIX_DRV_VER_MIN) Driver version strings are pretty pointless. What you really want to know if the specific kernel version. > + > +#define FELIX_PORT_RES_START 0x0100000 > +#define FELIX_PORT_RES_SIZE 0x10000 This should really be in device tree. You then get a lot closer to the binding for mscc-ocelot, and you can reuse more of its code. > +static void felix_release_ports(struct ocelot *ocelot) > +{ > + struct ocelot_port *ocelot_port; > + struct phy_device *phydev; > + struct device_node *dn; > + int i; > + > + for (i = 0; i < ocelot->num_phys_ports; i++) { > + ocelot_port = ocelot->ports[i]; > + if (!ocelot_port || !ocelot_port->phy || !ocelot_port->dev) > + continue; Phys are often optional, e.g. an RGMII interface to another switch, or an SFP port. > + > + phydev = ocelot_port->phy; > + unregister_netdev(ocelot_port->dev); > + free_netdev(ocelot_port->dev); > + > + if (phy_is_pseudo_fixed_link(phydev)) { > + dn = phydev->mdio.dev.of_node; > + /* decr refcnt: of_phy_register_fixed_link */ > + of_phy_deregister_fixed_link(dn); > + } > + phy_device_free(phydev); /* decr refcnt: of_phy_find_device */ To be on the safe side, you should probably not free the netdev until you free the phydev. This function also seems pretty generic. Should it be shared? > +static int felix_ports_init(struct pci_dev *pdev) > +{ > + struct ocelot *ocelot = pci_get_drvdata(pdev); > + struct device_node *np = ocelot->dev->of_node; > + struct device_node *phy_node, *portnp; > + struct phy_device *phydev; > + void __iomem *port_regs; > + resource_size_t base; > + u32 port; > + int err; > + > + ocelot->num_phys_ports = FELIX_MAX_NUM_PHY_PORTS; > + > + np = of_get_child_by_name(np, "ethernet-ports"); > + if (!np) { > + dev_err(&pdev->dev, "ethernet-ports sub-node not found\n"); > + return -ENODEV; > + } > + > + /* alloc netdev for each port */ > + err = ocelot_init(ocelot); > + if (err) > + return err; > + > + base = pci_resource_start(pdev, FELIX_SWITCH_BAR); > + for_each_available_child_of_node(np, portnp) { > + struct resource res = {}; > + int phy_mode; > + > + if (!portnp || !portnp->name || > + of_node_cmp(portnp->name, "port") || The name of the node should not matter. > +static int felix_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id) > +{ > + > + register_netdevice_notifier(&ocelot_netdevice_nb); > + register_switchdev_notifier(&ocelot_switchdev_nb); > + register_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb); This is also shared. So maybe move it into a common function? > + > + dev_info(&pdev->dev, "%s v%s\n", FELIX_DRV_STR, FELIX_DRV_VER_STR); > + return 0; > + > +err_ports_init: > +err_chip_init: > +err_sw_core_init: > + pci_iounmap(pdev, regs); > +err_iomap: > +err_resource_len: > +err_alloc_ocelot: > +err_dma: > + pci_disable_device(pdev); > + > + return err; > +} > + > +static void felix_pci_remove(struct pci_dev *pdev) > +{ > + struct ocelot *ocelot; > + > + ocelot = pci_get_drvdata(pdev); > + > + /* stop workqueue thread */ > + ocelot_deinit(ocelot); > + unregister_switchdev_blocking_notifier(&ocelot_switchdev_blocking_nb); > + unregister_switchdev_notifier(&ocelot_switchdev_nb); > + unregister_netdevice_notifier(&ocelot_netdevice_nb); This is also common. Andrew ^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver 2019-06-22 20:57 ` Andrew Lunn @ 2019-06-24 13:19 ` Claudiu Manoil 0 siblings, 0 replies; 25+ messages in thread From: Claudiu Manoil @ 2019-06-24 13:19 UTC (permalink / raw) To: Andrew Lunn Cc: David S . Miller, devicetree, Alexandre Belloni, netdev, Alexandru Marginean, linux-kernel, UNGLinuxDriver, Allan Nielsen, Rob Herring, Catalin Horghidan, linux-arm-kernel >-----Original Message----- >From: Andrew Lunn <andrew@lunn.ch> >Sent: Saturday, June 22, 2019 11:57 PM >To: Claudiu Manoil <claudiu.manoil@nxp.com> [...] Ok for all, I can work more on refactoring if we agree on the basics. For instance I can change the driver to use reg-names, same as mscc-ocelot, and factor out the common code. So far my intention was to change the ocelot part as little as possible, only where necessary. Thanks, Claudiu ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2019-07-07 21:15 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-21 15:38 [PATCH net-next 0/6] Microsemi Felix switch support Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 1/6] ocelot: Filter out ocelot SoC specific PCS config from common path Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 2/6] ocelot: Refactor common ocelot probing code to ocelot_init Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 3/6] ocelot: Factor out resource ioremap and regmap init common code Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 4/6] arm64: dts: fsl: ls1028a: Add Felix switch port DT node Claudiu Manoil 2019-06-21 16:49 ` Andrew Lunn 2019-06-24 11:45 ` Claudiu Manoil 2019-06-24 11:55 ` Alexandre Belloni 2019-06-24 14:26 ` Andrew Lunn 2019-06-24 15:23 ` Allan W. Nielsen 2019-06-24 16:24 ` Andrew Lunn 2019-06-24 18:26 ` Alexandre Belloni 2019-07-04 23:32 ` Vladimir Oltean 2019-07-05 4:49 ` Andrew Lunn 2019-07-05 8:37 ` Claudiu Manoil 2019-07-05 13:19 ` Andrew Lunn 2019-07-05 9:08 ` Vladimir Oltean 2019-07-05 14:15 ` Andrew Lunn 2019-07-05 16:03 ` Florian Fainelli 2019-07-07 21:00 ` Vladimir Oltean 2019-07-07 21:15 ` Florian Fainelli 2019-06-21 15:38 ` [PATCH net-next 5/6] dt-bindings: net: Add DT bindings for Microsemi Felix Switch Claudiu Manoil 2019-06-21 15:38 ` [PATCH net-next 6/6] net/mssc/ocelot: Add basic Felix switch driver Claudiu Manoil 2019-06-22 20:57 ` Andrew Lunn 2019-06-24 13:19 ` Claudiu Manoil
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).