Messages in this thread | | | Subject | Re: [PATCH net-next 25/28] [RFC] net: dpaa: Convert to phylink | From | Sean Anderson <> | Date | Thu, 23 Jun 2022 18:39:08 -0400 |
| |
Hi Russell,
On 6/18/22 11:58 AM, Sean Anderson wrote: > Hi Russell, > > On 6/18/22 4:22 AM, Russell King (Oracle) wrote: >> On Fri, Jun 17, 2022 at 08:45:38PM -0400, Sean Anderson wrote: >>> Hi Russell, >>> >>> Thanks for the quick response. >>> ... >>> Yes, I've been using the debug prints in phylink extensively as part of >>> debugging :) >>> >>> In this case, I added a debug statement to phylink_resolve printing out >>> cur_link_state, link_state.link, and pl->phy_state.link. I could see that >>> the phy link state was up and the mac (pcs) state was down. By inspecting >>> the PCS's registers, I determined that this was because AN had not completed >>> (in particular, the link was up in BMSR). I believe that forcing in-band-status >>> (by setting ovr_an_inband) shouldn't be necessary, but I was unable to get a link >>> up on any interface without it. In particular, the pre-phylink implementation >>> disabled PCS AN only for fixed links (which you can see in patch 23). >> >> I notice that prior to patch 23, the advertisment register was set to >> 0x4001, but in phylink_mii_c22_pcs_encode_advertisement() we set it to >> 0x0001 (bit 14 being the acknowledge bit from the PCS to the PHY, which >> is normally managed by hardware. >> >> It may be worth testing whether setting bit 14 changes the behaviour. > > Thanks for the tip. I'll try that out on Monday.
Well, I was playing around with this some more, and I found that I could enable it if I set one of the 10G lanes to SGMII. Not sure what's going on there. It's possible one of the lanes is mismatched, but I'm still looking into it.
---
How is rate adaptation in the phy supposed to work? One of the 10G interfaces on the RDB is hooked up to an AQR113 which can adapt rates below 10G to XFI using pause frames. This is nice and all, but the problem is that phylink_get_linkmodes sees that we're using PHY_INTERFACE_MODE_10GKR and doesn't add any of the lower link speeds (just MAC_10000). This results in ethtool output of
Settings for eth6: Supported ports: [ ] Supported link modes: 10000baseT/Full 10000baseKX4/Full 10000baseKR/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10000baseT/Full 10000baseKX4/Full 10000baseKR/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: Unknown! Duplex: Unknown! (255) Auto-negotiation: on Port: MII PHYAD: 0 Transceiver: external Current message level: 0x00002037 (8247) drv probe link ifdown ifup hw Link detected: yes
The speed and duplex are "Unknown!" because the negotiated link mode (100Base-TX) doesn't intersect with the advertised link modes (10000Base-T etc). This is currently using genphy; does there need to be driver support for this sort of thing? Should the correct speed even be reported here? The MAC and PCS still need to be configured for XFI.
Another problem is that the rate adaptation is supposed to happen with pause frames. Unfortunately, pause frames are disabled:
Pause parameters for eth6: Autonegotiate: on RX: off TX: off RX negotiated: on TX negotiated: on
Maybe this is because phylink_mii_c45_pcs_get_state doesn't check for pause modes? The far end link partner of course doesn't necessarily support pause frames. I tried this with managed = "phy" and "in-band-status" and it didn't seem to make a difference.
--Sean
| |