netdev - Re: [PATCH RFC 00/10] net: phylink: improve PHY validation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d1521892-f891-430d-8d4e-f229231fbe96@quicinc.com>
Date: Fri, 24 Nov 2023 18:42:32 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
        Andrew Lunn
	<andrew@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>
CC: Broadcom internal kernel review list
	<bcm-kernel-feedback-list@...adcom.com>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Florian Fainelli
	<florian.fainelli@...adcom.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Marek Behún <kabel@...nel.org>,
        <netdev@...r.kernel.org>, Paolo Abeni <pabeni@...hat.com>
Subject: Re: [PATCH RFC 00/10] net: phylink: improve PHY validation



On 11/22/2023 11:30 PM, Russell King (Oracle) 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.
> 
> 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(-)

Tested on qca808x PHY, the interface mode switched between sgmii and
2500base-x.

Tested-by: Luo Jie <quic_luoj@...cinc.com>