From: Vladimir Oltean <vladimir.oltean@nxp.com> To: Colin Foster <colin.foster@in-advantage.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Steen Hegelund <Steen.Hegelund@microchip.com>, Russell King <linux@armlinux.org.uk>, Heiner Kallweit <hkallweit1@gmail.com>, Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, "David S. Miller" <davem@davemloft.net>, Florian Fainelli <f.fainelli@gmail.com>, Vivien Didelot <vivien.didelot@gmail.com>, Andrew Lunn <andrew@lunn.ch>, "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Manoil <claudiu.manoil@nxp.com> Subject: Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability Date: Sun, 11 Sep 2022 00:44:36 +0000 [thread overview] Message-ID: <20220911004435.7wa2ir3gl6w5qanx@skbuf> (raw) In-Reply-To: <YxuHF4UrUEJBKmcu@euler> On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote: > Regarding felix_phylink_get_caps() - does it make sense that > mac_capabilities would be the same for all ports? This is where I've > currently landed, and I want to make sure it doesn't have adverse > effects on vsc9959 or seville: > > static void felix_phylink_get_caps(struct dsa_switch *ds, int port, > struct phylink_config *config) > { > struct ocelot *ocelot = ds->priv; > struct felix *felix; > u32 modes; > int i; > > felix = ocelot_to_felix(ocelot); > modes = felix->info->port_modes[port]; > > /* This driver does not make use of the speed, duplex, pause or > * the advertisement in its mac_config, so it is safe to mark > * this driver as non-legacy. > */ > config->legacy_pre_march2020 = false; > > for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) > if (modes & felix_phy_match_table[i]) > __set_bit(i, config->supported_interfaces); The current shape of the SERDES driver used with VSC9959 and VSC9953 is such that dynamic changes to the SERDES protocol are not supported. So at least for these 2 switches, please keep setting just the current ocelot->ports[port]->phy_mode (i.e. what was set in the device tree). > > config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 | > MAC_100 | MAC_1000FD; > } > > (this might be two patches - one for the match table and one for the > mac_capabilities) > > Seemingly because net/dsa/port.c checks for phylink_validate before it > checks for mac_capabilties, it won't make a difference there, but this > seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII > port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c > ocelot_port_phylink_create()) I don't think there is any QSGMII port that supports 2500FD in VSC7514. In general, the frequency at which QSGMII operates would not be able to support that data rate. That must be an artefact of me copying and pasting code from Felix to Ocelot in commit e6e12df625f2 ("net: mscc: ocelot: convert to phylink"), later transformed by Russell in commit 7258aa5094db ("net: ocelot_net: use phylink_generic_validate()"). How about you do the other way around: populate config->mac_capabilities such that it unconditionally also includes MAC_2500FD. You may have noticed that phylink_generic_validate() calls phylink_get_linkmodes(), which contains a logical AND between the capabilities reported by the MAC, and the plausible capabilities given by state->interface. So it would be quite within the expectations of this API for phylink to exclude MAC_2500FD from mac_capabilities if PHY_INTERFACE_MODE_QSGMII is used. On the other hand, VSC9959 and VSC9953 do support actual 2.5G on internal interfaces (and on USXGMII, in the case of VSC9959). They don't use the generic phylink validation method right now, but it would be good, in case they get mechanically converted or something, to keep reporting MAC_2500FD whatever code you add right now.
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Oltean <vladimir.oltean@nxp.com> To: Colin Foster <colin.foster@in-advantage.com> Cc: "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org>, "netdev@vger.kernel.org" <netdev@vger.kernel.org>, Steen Hegelund <Steen.Hegelund@microchip.com>, Russell King <linux@armlinux.org.uk>, Heiner Kallweit <hkallweit1@gmail.com>, Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>, Eric Dumazet <edumazet@google.com>, "David S. Miller" <davem@davemloft.net>, Florian Fainelli <f.fainelli@gmail.com>, Vivien Didelot <vivien.didelot@gmail.com>, Andrew Lunn <andrew@lunn.ch>, "UNGLinuxDriver@microchip.com" <UNGLinuxDriver@microchip.com>, Alexandre Belloni <alexandre.belloni@bootlin.com>, Claudiu Manoil <claudiu.manoil@nxp.com> Subject: Re: [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability Date: Sun, 11 Sep 2022 00:44:36 +0000 [thread overview] Message-ID: <20220911004435.7wa2ir3gl6w5qanx@skbuf> (raw) In-Reply-To: <YxuHF4UrUEJBKmcu@euler> On Fri, Sep 09, 2022 at 11:33:59AM -0700, Colin Foster wrote: > Regarding felix_phylink_get_caps() - does it make sense that > mac_capabilities would be the same for all ports? This is where I've > currently landed, and I want to make sure it doesn't have adverse > effects on vsc9959 or seville: > > static void felix_phylink_get_caps(struct dsa_switch *ds, int port, > struct phylink_config *config) > { > struct ocelot *ocelot = ds->priv; > struct felix *felix; > u32 modes; > int i; > > felix = ocelot_to_felix(ocelot); > modes = felix->info->port_modes[port]; > > /* This driver does not make use of the speed, duplex, pause or > * the advertisement in its mac_config, so it is safe to mark > * this driver as non-legacy. > */ > config->legacy_pre_march2020 = false; > > for (i = 0; i < PHY_INTERFACE_MODE_MAX; i++) > if (modes & felix_phy_match_table[i]) > __set_bit(i, config->supported_interfaces); The current shape of the SERDES driver used with VSC9959 and VSC9953 is such that dynamic changes to the SERDES protocol are not supported. So at least for these 2 switches, please keep setting just the current ocelot->ports[port]->phy_mode (i.e. what was set in the device tree). > > config->mac_capabilities = MAC_SYM_PAUSE | MAC_ASYM_PAUSE | MAC_10 | > MAC_100 | MAC_1000FD; > } > > (this might be two patches - one for the match table and one for the > mac_capabilities) > > Seemingly because net/dsa/port.c checks for phylink_validate before it > checks for mac_capabilties, it won't make a difference there, but this > seems ... wrong? Or maybe it isn't wrong until I implement the QSGMII > port that supports 2500FD (as in drivers/net/ethernet/mscc/ocelot_net.c > ocelot_port_phylink_create()) I don't think there is any QSGMII port that supports 2500FD in VSC7514. In general, the frequency at which QSGMII operates would not be able to support that data rate. That must be an artefact of me copying and pasting code from Felix to Ocelot in commit e6e12df625f2 ("net: mscc: ocelot: convert to phylink"), later transformed by Russell in commit 7258aa5094db ("net: ocelot_net: use phylink_generic_validate()"). How about you do the other way around: populate config->mac_capabilities such that it unconditionally also includes MAC_2500FD. You may have noticed that phylink_generic_validate() calls phylink_get_linkmodes(), which contains a logical AND between the capabilities reported by the MAC, and the plausible capabilities given by state->interface. So it would be quite within the expectations of this API for phylink to exclude MAC_2500FD from mac_capabilities if PHY_INTERFACE_MODE_QSGMII is used. On the other hand, VSC9959 and VSC9953 do support actual 2.5G on internal interfaces (and on USXGMII, in the case of VSC9959). They don't use the generic phylink validation method right now, but it would be good, in case they get mechanically converted or something, to keep reporting MAC_2500FD whatever code you add right now. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-09-11 0:44 UTC|newest] Thread overview: 114+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-05-08 18:52 [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Colin Foster 2022-05-08 18:52 ` Colin Foster 2022-05-08 18:52 ` [RFC v8 net-next 01/16] pinctrl: ocelot: allow pinctrl-ocelot to be loaded as a module Colin Foster 2022-05-08 18:52 ` Colin Foster 2022-05-09 10:05 ` Vladimir Oltean 2022-05-09 10:05 ` Vladimir Oltean 2022-05-08 18:52 ` [RFC v8 net-next 02/16] pinctrl: microchip-sgpio: allow sgpio driver to be used " Colin Foster 2022-05-08 18:52 ` Colin Foster 2022-05-09 10:05 ` Vladimir Oltean 2022-05-09 10:05 ` Vladimir Oltean 2022-05-08 18:53 ` [RFC v8 net-next 03/16] net: ocelot: add interface to get regmaps when exernally controlled Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 04/16] net: mdio: mscc-miim: add ability to be used in a non-mmio configuration Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 21:14 ` Andy Shevchenko 2022-05-08 21:14 ` Andy Shevchenko 2022-05-08 18:53 ` [RFC v8 net-next 05/16] pinctrl: ocelot: " Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 8:37 ` Andy Shevchenko 2022-05-09 8:37 ` Andy Shevchenko 2022-05-08 18:53 ` [RFC v8 net-next 06/16] pinctrl: microchip-sgpio: " Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 8:44 ` Andy Shevchenko 2022-05-09 8:44 ` Andy Shevchenko 2022-05-09 22:19 ` Colin Foster 2022-05-09 22:19 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 07/16] resource: add define macro for register address resources Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 08/16] mfd: ocelot: add support for the vsc7512 chip via spi Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 9:02 ` Andy Shevchenko 2022-05-09 9:02 ` Andy Shevchenko 2022-05-09 23:15 ` Colin Foster 2022-05-09 23:15 ` Colin Foster 2022-08-19 16:50 ` Vladimir Oltean 2022-08-19 16:50 ` Vladimir Oltean 2022-05-09 10:52 ` Vladimir Oltean 2022-05-09 10:52 ` Vladimir Oltean 2022-05-09 23:49 ` Colin Foster 2022-05-09 23:49 ` Colin Foster 2022-05-09 17:20 ` Vladimir Oltean 2022-05-09 17:20 ` Vladimir Oltean 2022-05-10 0:30 ` Colin Foster 2022-05-10 0:30 ` Colin Foster 2022-05-10 15:32 ` Lee Jones 2022-05-10 15:32 ` Lee Jones 2022-05-10 16:13 ` Colin Foster 2022-05-10 16:13 ` Colin Foster 2022-05-12 9:49 ` Lee Jones 2022-05-12 9:49 ` Lee Jones 2022-05-12 15:03 ` Colin Foster 2022-05-12 15:03 ` Colin Foster 2022-05-10 15:58 ` Vladimir Oltean 2022-05-10 15:58 ` Vladimir Oltean 2022-05-10 16:02 ` Colin Foster 2022-05-10 16:02 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 09/16] net: mscc: ocelot: expose ocelot wm functions Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 10/16] net: dsa: felix: add configurable device quirks Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 11/16] net: mscc: ocelot: expose regfield definition to be used by other drivers Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 10:56 ` Vladimir Oltean 2022-05-09 10:56 ` Vladimir Oltean 2022-05-10 0:05 ` Colin Foster 2022-05-10 0:05 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 12/16] net: mscc: ocelot: expose stats layout " Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 13/16] net: mscc: ocelot: expose vcap_props structure Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 14/16] net: dsa: ocelot: add external ocelot switch control Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 16:27 ` Vladimir Oltean 2022-05-09 16:27 ` Vladimir Oltean 2022-05-10 0:02 ` Colin Foster 2022-05-10 0:02 ` Colin Foster 2022-05-08 18:53 ` [RFC v8 net-next 15/16] net: dsa: felix: add phylink_get_caps capability Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 10:34 ` Vladimir Oltean 2022-05-09 10:34 ` Vladimir Oltean 2022-05-10 0:23 ` Colin Foster 2022-05-10 0:23 ` Colin Foster 2022-05-09 17:30 ` Vladimir Oltean 2022-05-09 17:30 ` Vladimir Oltean 2022-05-10 0:55 ` Colin Foster 2022-05-10 0:55 ` Colin Foster 2022-05-09 17:58 ` Vladimir Oltean 2022-05-09 17:58 ` Vladimir Oltean 2022-09-09 18:33 ` Colin Foster 2022-09-09 18:33 ` Colin Foster 2022-09-09 19:20 ` Russell King (Oracle) 2022-09-09 19:20 ` Russell King (Oracle) 2022-09-09 19:30 ` Colin Foster 2022-09-09 19:30 ` Colin Foster 2022-09-11 0:44 ` Vladimir Oltean [this message] 2022-09-11 0:44 ` Vladimir Oltean 2022-05-08 18:53 ` [RFC v8 net-next 16/16] net: dsa: ocelot: utilize phylink_generic_validate Colin Foster 2022-05-08 18:53 ` Colin Foster 2022-05-09 17:13 ` [RFC v8 net-next 00/16] add support for VSC7512 control over SPI Vladimir Oltean 2022-05-09 17:13 ` Vladimir Oltean 2022-05-10 1:43 ` Colin Foster 2022-05-10 1:43 ` Colin Foster 2022-05-10 2:57 ` Colin Foster 2022-05-10 2:57 ` Colin Foster 2022-05-10 16:18 ` Vladimir Oltean 2022-05-10 16:18 ` Vladimir Oltean 2022-05-14 22:00 ` Colin Foster 2022-05-14 22:00 ` Colin Foster 2022-05-19 14:44 ` Vladimir Oltean 2022-05-19 14:44 ` Vladimir Oltean 2022-05-19 16:15 ` Colin Foster 2022-05-19 16:15 ` Colin Foster 2022-05-19 17:09 ` Vladimir Oltean 2022-05-19 17:09 ` Vladimir Oltean
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220911004435.7wa2ir3gl6w5qanx@skbuf \ --to=vladimir.oltean@nxp.com \ --cc=Steen.Hegelund@microchip.com \ --cc=UNGLinuxDriver@microchip.com \ --cc=alexandre.belloni@bootlin.com \ --cc=andrew@lunn.ch \ --cc=claudiu.manoil@nxp.com \ --cc=colin.foster@in-advantage.com \ --cc=davem@davemloft.net \ --cc=edumazet@google.com \ --cc=f.fainelli@gmail.com \ --cc=hkallweit1@gmail.com \ --cc=kuba@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux@armlinux.org.uk \ --cc=netdev@vger.kernel.org \ --cc=pabeni@redhat.com \ --cc=vivien.didelot@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.