From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: "Abhishek Chauhan (ABC)" <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>,
"Przemek Kitszel" <przemyslaw.kitszel@intel.com>,
<kernel@quicinc.com>
Subject: Re: [PATCH net v4 2/2] net: phy: aquantia: remove usage of phy_set_max_speed
Date: Sat, 28 Sep 2024 10:52:42 +0200 [thread overview]
Message-ID: <20240928105242.5fe7f0e1@fedora.home> (raw)
In-Reply-To: <048bbc09-b7e1-4f49-8eff-a2c6cec28d05@quicinc.com>
On Fri, 27 Sep 2024 12:42:36 -0700
"Abhishek Chauhan (ABC)" <quic_abchauha@quicinc.com> wrote:
> On 9/27/2024 9:37 AM, Maxime Chevallier wrote:
> > Hi,
> >
> > On Thu, 26 Sep 2024 18:05:53 -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.
> >>
> >> Instead use get_features to fix up Phy PMA capabilities for
> >> AQR111, AQR111B0, AQR114C and AQCS109
> >>
> >> 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")
> >> Link: https://lore.kernel.org/all/20240913011635.1286027-1-quic_abchauha@quicinc.com/T/
> >> Signed-off-by: Abhishek Chauhan <quic_abchauha@quicinc.com>
> >
> > [...]
> >
> >> +static int aqr111_get_features(struct phy_device *phydev)
> >> +{
> >> + unsigned long *supported = phydev->supported;
> >> + int ret;
> >> +
> >> + /* Normal feature discovery */
> >> + ret = genphy_c45_pma_read_abilities(phydev);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + /* PHY FIXUP */
> >> + /* Although the PHY sets bit 12.18.19, it does not support 10G modes */
> >> + linkmode_clear_bit(ETHTOOL_LINK_MODE_10000baseT_Full_BIT, supported);
> >> + linkmode_clear_bit(ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT, supported);
> >> + linkmode_clear_bit(ETHTOOL_LINK_MODE_10000baseKR_Full_BIT, supported);
> >> +
> >> + /* Phy supports Speeds up to 5G with Autoneg though the phy PMA says otherwise */
> >> + linkmode_or(supported, supported, phy_gbit_features);
> >> + /* Set the 5G speed if it wasn't set as part of the PMA feature discovery */
> >> + linkmode_set_bit(ETHTOOL_LINK_MODE_5000baseT_Full_BIT, supported);
> >> + linkmode_set_bit(ETHTOOL_LINK_MODE_2500baseT_Full_BIT, supported);
> >
> > As you are moving away from phy_set_max_speed(phydev, 5000), it should mean
> > that what used to be in the supported bits already contained the
> > 5GBaseT bit, as phy_set_max_speed simply clears the highest speeds.
> >
> > In such case, calling the newly introduced function from
> > patch 1 should be enough ?
> >
>
> Well i am not sure about how other phy(AQR111, AQR111B0, AQR114C and AQCS109) behaved,
> but based on my testing and observation with AQR115c, it was pretty clear that
> the phy did not advertise Autoneg capabilities, did not set lower speed such as 10M/100M/1000BaseT
> ,it did set capabilities beyond what is recommended in the data book.
>
> So the below mentioned phys such as
>
> AQR111, AQR111B0, AQR114C = supports speed up to 5Gbps which means i cannot use the function
> defined in the previous patch as that sets speeds up to 2.5Gbps and all lower speeds.
>
> AQCS109 = supports speed up to 2.5Gbps and hence i have reused the same function aqr115c_get_features
> as part of this patch.
I understand your point, and it's hard indeed to be sure that no
regression was introduced. It does feel like you're reading the PHY
features, then reconstructing them almost from scratch again, but given
that the PMA report looks totally incorrect, there not much choice
indeed. So that's fine for me then.
Maxime
next prev parent reply other threads:[~2024-09-28 8:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-27 1:05 [PATCH net v4 0/2] Fix AQR PMA capabilities Abhishek Chauhan
2024-09-27 1:05 ` [PATCH net v4 1/2] net: phy: aquantia: AQR115c fix up " Abhishek Chauhan
2024-09-27 16:24 ` Maxime Chevallier
2024-09-27 1:05 ` [PATCH net v4 2/2] net: phy: aquantia: remove usage of phy_set_max_speed Abhishek Chauhan
2024-09-27 16:37 ` Maxime Chevallier
2024-09-27 19:42 ` Abhishek Chauhan (ABC)
2024-09-28 8:52 ` Maxime Chevallier [this message]
2024-09-28 9:47 ` Russell King (Oracle)
2024-09-30 12:18 ` Andrew Lunn
2024-09-30 16:55 ` 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=20240928105242.5fe7f0e1@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=przemyslaw.kitszel@intel.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