netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Heiner Kallweit <hkallweit1@gmail.com>
Cc: "Broadcom internal kernel review list"
	<bcm-kernel-feedback-list@broadcom.com>,
	"David S. Miller" <davem@davemloft.net>,
	"Eric Dumazet" <edumazet@google.com>,
	"Florian Fainelli" <florian.fainelli@broadcom.com>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Marek Behún" <kabel@kernel.org>,
	netdev@vger.kernel.org, "Paolo Abeni" <pabeni@redhat.com>
Subject: [PATCH RFC 00/10] net: phylink: improve PHY validation
Date: Wed, 22 Nov 2023 15:30:42 +0000	[thread overview]
Message-ID: <ZV4eolj9AI0b37y6@shell.armlinux.org.uk> (raw)

Hi,

One of the issues which has concerned me about the rate matching
implenentation that we have is that phy_get_rate_matching() returns
whether rate matching will be used for a particular interface, and we
enquire only for one interface.

Aquantia PHYs can be programmed with the rate matching and interface
mode settings on a per-media speed basis using the per-speed vendor 1
global configuration registers.

Thus, it is possible for the PHY to be configured to use rate matching
for 10G, 5G, 2.5G with 10GBASE-R, and then SGMII for the remaining
speeds. Therefore, it clearly doesn't make sense to enquire about rate
matching for just one interface mode.

Also, PHYs that change their interfaces are handled sub-optimally, in
that we validate all the interface modes that the host supports, rather
than the interface modes that the PHY will use.

This patch series changes the way we validate PHYs, but in order to do
so, we need to know exactly which interface modes will be used by the
PHY. So that phylib can convey this information, we add
"possible_interfaces" to struct phy_device.

possible_interfaces is to be filled in by a phylib driver once the PHY
is configured (in other words in the PHYs .config_init method) with the
interface modes that it will switch between. This then allows users of
phylib to know which interface modes will be used by the PHY.

This allows us to solve both these issues: where possible_interfaces is
provided, we can validate which ethtool link modes can be supported by
looking at which interface modes that both the PHY and host support,
and request rate matching information for each mode.

This should improve the accuracy of the validation.

 drivers/net/phy/aquantia/aquantia.h      |   5 +
 drivers/net/phy/aquantia/aquantia_main.c |  76 +++++++++++-
 drivers/net/phy/bcm84881.c               |  12 ++
 drivers/net/phy/marvell10g.c             | 203 ++++++++++++++++++++-----------
 drivers/net/phy/phy_device.c             |   2 +
 drivers/net/phy/phylink.c                | 177 +++++++++++++++++++--------
 include/linux/phy.h                      |   3 +
 7 files changed, 353 insertions(+), 125 deletions(-)

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

             reply	other threads:[~2023-11-22 15:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-22 15:30 Russell King (Oracle) [this message]
2023-11-22 15:31 ` [PATCH RFC net-next 01/10] net: phy: add possible interfaces Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 02/10] net: phy: marvell10g: table driven mactype decode Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 03/10] net: phy: marvell10g: fill in possible_interfaces Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 04/10] net: phy: bcm84881: " Russell King (Oracle)
2023-11-22 22:11   ` Florian Fainelli
2023-11-22 15:31 ` [PATCH RFC net-next 05/10] net: phy: aquantia: fill in possible_interfaces for AQR113C Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 06/10] net: phylink: split out per-interface validation Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 07/10] net: phylink: pass PHY into phylink_validate_one() Russell King (Oracle)
2023-11-22 15:31 ` [PATCH RFC net-next 08/10] net: phylink: pass PHY into phylink_validate_mask() Russell King (Oracle)
2023-11-22 15:32 ` [PATCH RFC net-next 09/10] net: phylink: split out PHY validation from phylink_bringup_phy() Russell King (Oracle)
2023-11-22 15:32 ` [PATCH RFC net-next 10/10] net: phylink: use the PHY's possible_interfaces if populated Russell King (Oracle)
2023-11-24 10:42 ` [PATCH RFC 00/10] net: phylink: improve PHY validation Jie Luo
2023-11-24 12:25 ` [PATCH net-next " Russell King (Oracle)

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=ZV4eolj9AI0b37y6@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=hkallweit1@gmail.com \
    --cc=kabel@kernel.org \
    --cc=kuba@kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).