Re: [PATCH net-next v2 2/2] net: phy: aquantia: allow forcing order of MDI pairs

[Daniel Golle <daniel@makrotopia.org>]

On Thu, Aug 29, 2024 at 01:05:00AM +0200, Andrew Lunn wrote:
> On Wed, Aug 28, 2024 at 11:52:09PM +0100, Daniel Golle wrote:
> > Despite supporting Auto MDI-X, it looks like Aquantia only supports
> > swapping pair (1,2) with pair (3,6) like it used to be for MDI-X on
> > 100MBit/s networks.
> > 
> > When all 4 pairs are in use (for 1000MBit/s or faster) the link does not
> > come up with pair order is not configured correctly, either using
> > MDI_CFG pin or using the "PMA Receive Reserved Vendor Provisioning 1"
> > register.
> > 
> > Normally, the order of MDI pairs being either ABCD or DCBA is configured
> > by pulling the MDI_CFG pin.
> > 
> > However, some hardware designs require overriding the value configured
> > by that bootstrap pin. The PHY allows doing that by setting a bit in
> > "PMA Receive Reserved Vendor Provisioning 1" register which allows
> > ignoring the state of the MDI_CFG pin and another bit configuring
> > whether the order of MDI pairs should be normal (ABCD) or reverse
> > (DCBA). Pair polarity is not affected and remains identical in both
> > settings.
> > 
> > Introduce two mutually exclusive boolean properties which allow forcing
> > either normal or reverse order of the MDI pairs from DT.
> > 
> > If none of the two new properties is present, the behavior is unchanged
> > and MDI pair order configuration is untouched (ie. either the result of
> > MDI_CFG pin pull-up/pull-down, or pair order override already configured
> > by the bootloader before Linux is started).
> > 
> > Forcing normal pair order is required on the Adtran SDG-8733A Wi-Fi 7
> > residential gateway.
> 
> Is there an in-tree dts file for this? We like to see that options
> which are added are actually used.

I planning to submit DTS for all the Adtran 8700 series once the
MediaTek MT7988 SoC Ethernet is fully supported. At this point I'm still
waiting for feedback on how to organize the PCS drivers for that SoC,
see https://patchwork.kernel.org/comment/25954425/