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
| ||
|
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>
Powered by blists - more mailing lists