From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Hans-Frieder Vogt <hfdevel@gmx.net>
Cc: Hans-Frieder Vogt via B4 Relay
<devnull+hfdevel.gmx.net@kernel.org>,
Andrew Lunn <andrew@lunn.ch>,
Heiner Kallweit <hkallweit1@gmail.com>,
Russell King <linux@armlinux.org.uk>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
FUJITA Tomonori <fujita.tomonori@gmail.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v5 4/7] net: phy: aquantia: add essential functions to aqr105 driver
Date: Tue, 25 Feb 2025 10:38:12 +0100 [thread overview]
Message-ID: <20250225103812.7e436d17@fedora.home> (raw)
In-Reply-To: <d944c0bd-a652-4bfe-b6e8-c264f5b36562@gmx.net>
On Sun, 23 Feb 2025 23:26:49 +0100
Hans-Frieder Vogt <hfdevel@gmx.net> wrote:
> Hi Maxime,
>
> On 23.02.2025 11.32, Maxime Chevallier wrote:
> > Hi,
> >
> > On Sat, 22 Feb 2025 10:49:31 +0100
> > Hans-Frieder Vogt via B4 Relay <devnull+hfdevel.gmx.net@kernel.org>
> > wrote:
> >
> >> From: Hans-Frieder Vogt <hfdevel@gmx.net>
> >>
> >> This patch makes functions that were provided for aqr107 applicable to
> >> aqr105, or replaces generic functions with specific ones. Since the aqr105
> >> was introduced before NBASE-T was defined (or 802.3bz), there are a number
> >> of vendor specific registers involved in the definition of the
> >> advertisement, in auto-negotiation and in the setting of the speed. The
> >> functions have been written following the downstream driver for TN4010
> >> cards with aqr105 PHY, and use code from aqr107 functions wherever it
> >> seemed to make sense.
> >>
> >> Signed-off-by: Hans-Frieder Vogt <hfdevel@gmx.net>
> >> ---
> >> drivers/net/phy/aquantia/aquantia_main.c | 242 ++++++++++++++++++++++++++++++-
> >> 1 file changed, 240 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/net/phy/aquantia/aquantia_main.c b/drivers/net/phy/aquantia/aquantia_main.c
> >> index 86b0e63de5d88fa1050919a8826bdbec4bbcf8ba..38c6cf7814da1fb9a4e715f242249eee15a3cc85 100644
> >> --- a/drivers/net/phy/aquantia/aquantia_main.c
> >> +++ b/drivers/net/phy/aquantia/aquantia_main.c
> >> @@ -33,6 +33,9 @@
> >> #define PHY_ID_AQR115C 0x31c31c33
> >> #define PHY_ID_AQR813 0x31c31cb2
> >>
> >> +#define MDIO_AN_10GBT_CTRL_ADV_LTIM BIT(0)
> > This is a standard C45 definition, from :
> > 45.2.7.10.15 10GBASE-T LD loop timing ability (7.32.0)
> >
> > So if you need this advertising capability, you should add that in the
> > generic definitions for C45 registers in include/uapi/linux/mdio.h
> Thanks. Wasn't aware this being a standard definition.
>
> Wouldn't the definition
> #define ADVERTISE_XNP BIT(12)
> then need to go to include/uapi/linux/mii.h accordingly?
Looks like this is indeed part of the standard now, in
28.2.4.1.3 Auto-Negotiation advertisement register (Register 4), so it seems
to be the right move to modify ADVERTISE_RESV into ADVERTISE_XNP.
> There, bit 12 is currently named ADVERTISE_RESV and commented as unused
> (which it obviously is not, because it is used in
> drivers/net/ethernet/sfc/falcon/mdio_10g.c
One note is that this driver uses the C45 MMD 7 AN register layout :
45.2.7.1 AN control register (Register 7.0)
in which the eXtended Next Page bit is BIT(13).
That actually leads to an interesting point, as it appears the at803x.c
driver mixes both, which looks incorrect to me :
/* Ar803x extended next page bit is enabled by default. Cisco
* multigig switches read this bit and attempt to negotiate 10Gbps
* rates even if the next page bit is disabled. This is incorrect
* behaviour but we still need to accommodate it. XNP is only needed
* for 10Gbps support, so disable XNP.
*/
return phy_modify(phydev, MII_ADVERTISE, MDIO_AN_CTRL1_XNP, 0);
In such case, BIT(13) fot MII_ADVERTISE is ADVERTISE_RFAULT, if my
understanding of the spec is correct.
> I think, for now, I will just do the same as in the falcon driver and
> use ADVERTISE_RESV instead. Then it may be renamed later in all places.
Make sure you use the BIT(12) in your case indeed, looks to be the
right way in that case.
> >
> > That being said, as it looks this is the first driver using this
> > feature, do you actually need to advertise Loop Timing ability here ?
> > I guess it comes from the vendor driver ?
> you are right. The code just tries to replicate the vendor code.
> However, I have now tested the driver without this flag and haven't
> noticed any unusual behavior. So, I guess, it works indeed without.
> I'll remove the flag in the next revision of the patch.
So in that case, no need to define MDIO_AN_10GBT_CTRL_ADV_LTIM at all :)
Thanks,
Maxime
next prev parent reply other threads:[~2025-02-25 9:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-22 9:49 [PATCH net-next v5 0/7] net: tn40xx: add support for AQR105 based cards Hans-Frieder Vogt via B4 Relay
2025-02-22 9:49 ` [PATCH net-next v5 1/7] net: phy: Add swnode support to mdiobus_scan Hans-Frieder Vogt via B4 Relay
2025-02-22 9:49 ` [PATCH net-next v5 2/7] net: phy: aquantia: add probe function to aqr105 for firmware loading Hans-Frieder Vogt via B4 Relay
2025-02-22 9:49 ` [PATCH net-next v5 3/7] net: phy: aquantia: search for firmware-name in fwnode Hans-Frieder Vogt via B4 Relay
2025-02-22 9:49 ` [PATCH net-next v5 4/7] net: phy: aquantia: add essential functions to aqr105 driver Hans-Frieder Vogt via B4 Relay
2025-02-23 10:32 ` Maxime Chevallier
2025-02-23 22:26 ` Hans-Frieder Vogt
2025-02-25 9:38 ` Maxime Chevallier [this message]
2025-02-22 9:49 ` [PATCH net-next v5 5/7] net: tn40xx: create swnode for mdio and aqr105 phy and add to mdiobus Hans-Frieder Vogt via B4 Relay
2025-02-24 4:08 ` Ratheesh Kannoth
2025-02-24 18:11 ` Hans-Frieder Vogt
2025-02-22 9:49 ` [PATCH net-next v5 6/7] net: tn40xx: prepare tn40xx driver to find phy of the TN9510 card Hans-Frieder Vogt via B4 Relay
2025-02-22 9:49 ` [PATCH net-next v5 7/7] net: tn40xx: add pci-id of the aqr105-based Tehuti TN4010 cards Hans-Frieder Vogt via B4 Relay
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=20250225103812.7e436d17@fedora.home \
--to=maxime.chevallier@bootlin.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=devnull+hfdevel.gmx.net@kernel.org \
--cc=edumazet@google.com \
--cc=fujita.tomonori@gmail.com \
--cc=hfdevel@gmx.net \
--cc=hkallweit1@gmail.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.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