From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Abhishek Chauhan <quic_abchauha@quicinc.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Andrew Halaney <ahalaney@redhat.com>,
"Russell King (Oracle)" <linux@armlinux.org.uk>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
Brad Griffis <bgriffis@nvidia.com>,
Vladimir Oltean <vladimir.oltean@nxp.com>,
Jon Hunter <jonathanh@nvidia.com>,
kernel@quicinc.com
Subject: Re: [PATCH net v2] net: phy: aquantia: Introduce custom get_features
Date: Tue, 24 Sep 2024 10:24:33 +0200 [thread overview]
Message-ID: <20240924102433.3ff11d20@fedora.home> (raw)
In-Reply-To: <20240924055251.3074850-1-quic_abchauha@quicinc.com>
Hi,
On Mon, 23 Sep 2024 22:52:51 -0700
Abhishek Chauhan <quic_abchauha@quicinc.com> wrote:
> Remove the use of phy_set_max_speed in phy driver as the
> function is mainly used in MAC driver to set the max
> speed.
>
> Introduce custom get_features for AQR family of chipsets
>
> 1. such as AQR111/B0/114c which supports speeds up to 5Gbps
> 2. such as AQR115c/AQCS109 which supports speeds up to 2.5Gbps
>
> Fixes: 038ba1dc4e54 ("net: phy: aquantia: add AQR111 and AQR111B0 PHY ID")
> Fixes: 0974f1f03b07 ("net: phy: aquantia: remove false 5G and 10G speed ability for AQCS109")
> Fixes: c278ec644377 ("net: phy: aquantia: add support for AQR114C PHY ID")
> Fixes: 0ebc581f8a4b ("net: phy: aquantia: add support for aqr115c")
> Link: https://lore.kernel.org/all/20240913011635.1286027-1-quic_abchauha@quicinc.com/T/
> Signed-off-by: Abhishek Chauhan <quic_abchauha@quicinc.com>
> ---
> Changes since v1
> 1. remove usage of phy_set_max_speed in the aquantia driver code.
> 2. Introduce aqr_custom_get_feature which checks for the phy id and
> takes necessary actions based on max_speed supported by the phy
> 3. remove aqr111_config_init as it is just a wrapper function.
>
> output from my device looks like :-
> 1. Link is up with 2.5Gbps with 2500BaseX with autoneg on.
>
>
> Settings for eth0:
> Supported ports: [ TP FIBRE ]
> Supported link modes: 10baseT/Full
> 100baseT/Full
> 1000baseT/Full
> 2500baseX/Full
> 2500baseT/Full
> Supported pause frame use: Symmetric Receive-only
> Supports auto-negotiation: Yes
> Supported FEC modes: Not reported
> Advertised link modes: 10baseT/Full
> 100baseT/Full
> 1000baseT/Full
> 2500baseX/Full
> 2500baseT/Full
>
[...]
> +static void aqr_supported_speed(struct phy_device *phydev, u32 max_speed)
> +{
> + __ETHTOOL_DECLARE_LINK_MODE_MASK(supported) = { 0, };
> +
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Autoneg_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Pause_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_Asym_Pause_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_FIBRE_BIT, supported);
Can this PHY actually support FIBRE ports ? What you must list here are
the modes that the PHY can support on the LP side. I'm not familiar
with this PHY, but from what I can see from the current driver, there's
no such support yet in the driver.
> + linkmode_set_bit(ETHTOOL_LINK_MODE_TP_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Half_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_10baseT_Full_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Half_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_100baseT_Full_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Half_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_1000baseT_Full_BIT, supported);
> +
> + if (max_speed == SPEED_2500) {
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseX_Full_BIT, supported);
If the PHY is strictly BaseT, then you shouldn't specify 2500BaseX as
supported
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, supported);
> + } else if (max_speed == SPEED_5000) {
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseX_Full_BIT, supported);
Same here
> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, supported);
> + linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, supported);
> + }
> +
> + linkmode_copy(phydev->supported, supported);
> +}
> +
> +static int aqr_custom_get_feature(struct phy_device *phydev)
> +{
> + switch (phydev->drv->phy_id) {
> + case PHY_ID_AQR115C:
> + case PHY_ID_AQCS109:
> + aqr_supported_speed(phydev, SPEED_2500);
> + break;
> + case PHY_ID_AQR111:
> + case PHY_ID_AQR111B0:
> + case PHY_ID_AQR114C:
> + aqr_supported_speed(phydev, SPEED_5000);
> + break;
> + }
> + return 0;
> +}
You could define one .get_feature for the 2.5G PHYs and another for the
5G phys, that would avoid having to modify this single helper for each
new PHY.
Thanks,
Maxime
next prev parent reply other threads:[~2024-09-24 8:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-24 5:52 [PATCH net v2] net: phy: aquantia: Introduce custom get_features Abhishek Chauhan
2024-09-24 8:24 ` Maxime Chevallier [this message]
2024-09-24 15:17 ` Abhishek Chauhan (ABC)
2024-09-24 8:36 ` Russell King (Oracle)
2024-09-24 15:18 ` Abhishek Chauhan (ABC)
2024-09-24 8:46 ` Przemek Kitszel
2024-09-24 15:18 ` Abhishek Chauhan (ABC)
2024-09-24 12:04 ` Andrew Lunn
2024-09-24 15:19 ` Abhishek Chauhan (ABC)
2024-09-25 0:49 ` Abhishek Chauhan (ABC)
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=20240924102433.3ff11d20@fedora.home \
--to=maxime.chevallier@bootlin.com \
--cc=ahalaney@redhat.com \
--cc=andrew@lunn.ch \
--cc=bartosz.golaszewski@linaro.org \
--cc=bgriffis@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkallweit1@gmail.com \
--cc=jonathanh@nvidia.com \
--cc=kernel@quicinc.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=quic_abchauha@quicinc.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 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).