From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.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: Fri, 9 Sep 2022 11:33:59 -0700 [thread overview]
Message-ID: <YxuHF4UrUEJBKmcu@euler> (raw)
In-Reply-To: <20220509175806.osytlqnrri6t3g6r@skbuf>
On Mon, May 09, 2022 at 05:58:07PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> > Hmm... So the main reason I needed get_caps was because
> > phylink_generic_validate looks at mac_capabilities. I know I'll have to
> > deal with supported_interfaces once I finally get the other four ports
> > working, but for now the main purpose of this patch is to allow me to
> > populate the mac_capabilities entry for phylink_generic_validate.
> >
> > Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> > of the patch makes sense.
>
> But still. Just populate mac_capabilities for everybody in the common
> felix_phylink_get_caps(), and use the generic phylink validation only
> for your driver.
Resurrecting this thread, now that I'm back into the networking stuff. I
removed some people from the CC chain who I think were MFD / GPIO specific.
v1 of my upcoming "add dsa capabilities to the vsc7512" will build off
these suggestions, but these DSA patches were dropped in the MFD set.
Restoring context: my oritinal patch was:
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
struct phylink_config *config)
{
struct ocelot *ocelot = ds->priv;
+ struct felix *felix;
- /* 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;
+ felix = ocelot_to_felix(ocelot);
+
+ if (felix->info->phylink_get_caps) {
+ felix->info->phylink_get_caps(ocelot, port, config);
+ } else {
- __set_bit(ocelot->ports[port]->phy_mode,
- config->supported_interfaces);
+ /* 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;
+
+ __set_bit(ocelot->ports[port]->phy_mode,
+ config->supported_interfaces);
+ }
}
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);
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())
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Colin Foster <colin.foster@in-advantage.com>
To: Vladimir Oltean <vladimir.oltean@nxp.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: Fri, 9 Sep 2022 11:33:59 -0700 [thread overview]
Message-ID: <YxuHF4UrUEJBKmcu@euler> (raw)
In-Reply-To: <20220509175806.osytlqnrri6t3g6r@skbuf>
On Mon, May 09, 2022 at 05:58:07PM +0000, Vladimir Oltean wrote:
> On Mon, May 09, 2022 at 05:55:37PM -0700, Colin Foster wrote:
> > Hmm... So the main reason I needed get_caps was because
> > phylink_generic_validate looks at mac_capabilities. I know I'll have to
> > deal with supported_interfaces once I finally get the other four ports
> > working, but for now the main purpose of this patch is to allow me to
> > populate the mac_capabilities entry for phylink_generic_validate.
> >
> > Aside from ensuring legacy_pre_march2020 = false, I feel like the rest
> > of the patch makes sense.
>
> But still. Just populate mac_capabilities for everybody in the common
> felix_phylink_get_caps(), and use the generic phylink validation only
> for your driver.
Resurrecting this thread, now that I'm back into the networking stuff. I
removed some people from the CC chain who I think were MFD / GPIO specific.
v1 of my upcoming "add dsa capabilities to the vsc7512" will build off
these suggestions, but these DSA patches were dropped in the MFD set.
Restoring context: my oritinal patch was:
+++ b/drivers/net/dsa/ocelot/felix.c
@@ -982,15 +982,23 @@ static void felix_phylink_get_caps(struct dsa_switch *ds, int port,
struct phylink_config *config)
{
struct ocelot *ocelot = ds->priv;
+ struct felix *felix;
- /* 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;
+ felix = ocelot_to_felix(ocelot);
+
+ if (felix->info->phylink_get_caps) {
+ felix->info->phylink_get_caps(ocelot, port, config);
+ } else {
- __set_bit(ocelot->ports[port]->phy_mode,
- config->supported_interfaces);
+ /* 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;
+
+ __set_bit(ocelot->ports[port]->phy_mode,
+ config->supported_interfaces);
+ }
}
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);
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())
next prev parent reply other threads:[~2022-09-09 18:35 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 [this message]
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
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=YxuHF4UrUEJBKmcu@euler \
--to=colin.foster@in-advantage.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=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 \
--cc=vladimir.oltean@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is 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.