Re: [PATCH v5 3/6] net: phy: at803x: add QCA8084 ethernet phy support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 11/23/2023 8:01 PM, Russell King (Oracle) wrote:
On Thu, Nov 23, 2023 at 06:57:59PM +0800, Jie Luo wrote:
On 11/21/2023 7:52 PM, Russell King (Oracle) wrote:
Ultimately, you will need a way to use inband signalling with Cisco
SGMII for 10M/100M/1G speeds, and then switch to 2500base-X when
operating at 2.5G speeds, and that is done via the PHY driver
updating phydev->interface.

What we do need is some way for the PHY to also tell the PCS/MAC
whether inband should be used. This is something I keep bringing up
and now that we have PCS drivers revised to use the value from
phylink_pcs_neg_mode() _and_ a consistent implementation amongst them
we can now think about signalling to PCS drivers whether inband mode
needs to be turned off when switching between modes.

Yes, we can switch the interface mode according to the current link
speed in the pcs driver.
but the issue is that the phy-mode i specified for the PHYLINK,
if phy-mode is sgmii, the support capability is limited to maximum
capability 1G during the PHYLINK setup and i can't configure it to 2.5G
dynamically, if the phy-mode is 2500base-x, then PHY capability will
be modified to only support 2.5G, other speeds can't be linked up.

So you need my patches that add "possible_interfaces" to phylib so you
can tell phylink that you will be switching between SGMII and
2500base-X. Please see the RFC posting of those patches I sent
yesterday and try them out - you will need to modify your phylib
driver to fill in phydev->possible_interfaces.

Your patches work on my board, thanks Russell.


There have been patches in the past that allow inband mode to be
queried from phylib, and this is another important component in
properly dealing with PHYs that need to use inband signalling with
Cisco SGMII, but do not support inband signalling when operating at
2.5G speeds. The problem when operating at 2.5G speed is that the
base-X protocols are normally for use over fibre, which is the media,
and therefore the ethtool Autoneg bit should define whether inband
gets used or not. However, in the case of a PHY using 2500base-X,
the Autoneg bit continues to define whether autonegotiation should
be used on the media, and in this case it's the media side of the
PHY rather than the 2500base-X link.

So, when using a 2500base-X link to a PHY, we need to disregard the
Autoneg bit, but that then raises the question about how we should
configure it - and one solution to that would be to entire of phylib
what the PHY wants to do. Another is to somehow ask the PCS driver
whether it supports inband signalling at 2500base-X, and resolve
those capabilities.

For the qca808x PHY, when it is linked in 2.5G, the autoneg is also
disabled in PCS hardware, so the sgmii+ of qca808x PHY is almost
same as 2500base-X.

Not "almost". It _is_ the same. This is the point I've been trying
to get across to you. Without inband signalling, 1000base-X and SGMII
(when operating at 1G) are _identical_ and entirely compatible.

You've said that your 2.5G "SGMII" mode has inband signalling disabled,
and thus it without inband signalling, 2500base-X and this 2.5G mode
are again identical and entirely compatible. There's no "almost" about
it.


Yes, confirmed with HW guy, they work on the same way.




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux