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]
Date:   Fri, 29 Apr 2022 03:35:43 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Robert Hancock <robert.hancock@...ian.com>
Cc:     netdev@...r.kernel.org, hkallweit1@...il.com,
        linux@...linux.org.uk, davem@...emloft.net, kuba@...nel.org,
        pabeni@...hat.com
Subject: Re: [PATCH net-next] net: phy: marvell: update abilities and
 advertising when switching to SGMII

On Wed, Apr 27, 2022 at 01:39:28PM -0600, Robert Hancock wrote:
> With some SFP modules, such as Finisar FCLF8522P2BTL, the PHY hardware
> strapping defaults to 1000BaseX mode, but the kernel prefers to set them
> for SGMII mode.

Is this the SFP code determining this? Its copper == use SGMII?

> When this happens and the PHY is soft reset, the BMSR
> status register is updated, but this happens after the kernel has already
> read the PHY abilities during probing. This results in support not being
> detected for, and the PHY not advertising support for, 10 and 100 Mbps
> modes, preventing the link from working with a non-gigabit link partner.
> 
> When the PHY is being configured for SGMII mode, call genphy_read_abilities
> again in order to re-read the capabilities, and update the advertising
> field accordingly.

Is this actually a generic problem? There are other PHYs used in SFP
modules, and i assume they also could have their mode changed. So
should the re-reading of the abilities be in the core, not each
driver?

	Andrew

Powered by blists - more mailing lists