On Tue, Jul 14, 2020 at 11:49:58AM +0300, Vladimir Oltean wrote: > Are you going to post a non-RFC version?
I'm waiting for the remaining patches to be reviewed; Florian reviewed the first six patches (which are not the important ones in the series) and that seems to be where things have stopped. There has been no change, so I don't see there's much point to reposting the series. I'd actually given up pushing this further; I've seen patches go by that purpetuate the idea that the PCS is handled by phylib. I feel like I'm wasting my time with this. > I think this series makes a lot of sense overall and is a good > consolidation for the type of interfaces that are already established in > Linux. > > This changes the landscape of how Linux is dealing with a MAC-side > clause 37 PCS, and should constitute a workable base even for clause 49 > PCSs when those use a clause 37 auto-negotiation system (like USXGMII > and its various multi-port variants). Yes. > Where I have some doubts is a > clause 49 PCS which uses a clause 73 auto-negotiation system, I would > like to understand your vision of how deep phylink is going to go into > the PMD layer, especially where it is not obvious that said layer is > integrated with the MAC. I have only considered up to 10GBASE-R based systems as that is the limit of what I can practically test here. I have one system that offers a QSFP+ cage, and I have a QSFP+ to 4x SFP+ (10G) splitter cable - so that's basically 4x 10GBASE-CR rather than 40GBASE-CR. I am anticipating that clause 73 will be handled in a very similar way to clause 37. The clause 73 "technology ability" field defines the capabilities of the link, but as we are finding with 10GBASE-R based setups with copper PHYs, the capabilities of the link may not be what we want to report to the user, especially if the copper PHY is capable of rate adaption. Hence, it may be possible to have a backplane link that connects to a copper PHY that does rate adaption: MAC <--> Clause 73 PCS <--backplane--> PHY <--base-T--> remote system This is entirely possible from what I've seen in one NBASE-T PHY datasheet. The PHY is documented as being capable of negotiating a 10GBASE-KR link with the host system, while offering 10GBASE-R, 1000BASE-X, 10GBASE-T, 5GBASE-T, 2.5GBASE-T, 1GBASE-T, 100BASE-T, and 10BASE-T on the media side. The follow-on question is whether that PHY is likely to be accessible to the system on the other end of the backplane link somehow - either through some kind of firmware link or direct access. That is not possible to know without having experience with such systems. That said, with the splitting of the PCS from the MAC in phylink, there is the possibility for the PCS to be implemented as an entirely separate driver to the MAC driver, although there needs to be some infrastructure to make that work sanely. Right now, it is the MAC responsibility to attach the PCS to phylink, which is the right way to handle it for setups where the PCS is closely tied to the MAC, such as Marvell NETA and PP2 where the PCS is indistinguishable from the MAC, and will likely remain so for such setups. However, if we need to also support entirely separate PCS, I don't see any big issues with that now that we have this split. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
