mbox series

[net-next,00/10] net: phylink: improve PHY validation

Message ID ZWCWn+uNkVLPaQhn@shell.armlinux.org.uk (mailing list archive)
Headers show
Series net: phylink: improve PHY validation | expand

Message

Russell King (Oracle) Nov. 24, 2023, 12:27 p.m. UTC
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.

Sending this out again without RFC as Jie Luo will need it for the
QCA8084 changes. No changes except to add the attributations already
received. Thanks!

And I'll send the cover message again without threading it to the
previous series!

 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(-)

Comments

Jakub Kicinski Nov. 28, 2023, 2:08 a.m. UTC | #1
On Fri, 24 Nov 2023 12:27:11 +0000 Russell King (Oracle) wrote:
> 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.

FTR this series got marked as Changes Requested in pw, but I don't see
any reason why, so reviving it (to immediately apply it):

pw-bot: under-review
patchwork-bot+netdevbpf@kernel.org Nov. 28, 2023, 2:20 a.m. UTC | #2
Hello:

This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Fri, 24 Nov 2023 12:27:11 +0000 you wrote:
> 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.
> 
> [...]

Here is the summary with links:
  - [net-next,01/10] net: phy: add possible interfaces
    https://git.kernel.org/netdev/net-next/c/243ad8df7a1b
  - [net-next,02/10] net: phy: marvell10g: table driven mactype decode
    https://git.kernel.org/netdev/net-next/c/2cb6d63b30c6
  - [net-next,03/10] net: phy: marvell10g: fill in possible_interfaces
    https://git.kernel.org/netdev/net-next/c/82f2e76b660a
  - [net-next,04/10] net: phy: bcm84881: fill in possible_interfaces
    https://git.kernel.org/netdev/net-next/c/a22583338e53
  - [net-next,05/10] net: phy: aquantia: fill in possible_interfaces for AQR113C
    https://git.kernel.org/netdev/net-next/c/01972fa9ab7d
  - [net-next,06/10] net: phylink: split out per-interface validation
    https://git.kernel.org/netdev/net-next/c/5f492a04506e
  - [net-next,07/10] net: phylink: pass PHY into phylink_validate_one()
    https://git.kernel.org/netdev/net-next/c/385e72b40034
  - [net-next,08/10] net: phylink: pass PHY into phylink_validate_mask()
    https://git.kernel.org/netdev/net-next/c/b7014f9ece50
  - [net-next,09/10] net: phylink: split out PHY validation from phylink_bringup_phy()
    https://git.kernel.org/netdev/net-next/c/2c62ff83ee14
  - [net-next,10/10] net: phylink: use the PHY's possible_interfaces if populated
    https://git.kernel.org/netdev/net-next/c/7a1f9a17ee99

You are awesome, thank you!