[1]
In eTSEC, I believe there were just config register bits to enable PAUSE flow control.
How do we enable/disable on DPAAx and confirm the setting?
I imagine 'ethtool' in Linux would be a convenient way.
In memac the bits for PAUSE are PAUSE_IGN and RX_SECTION_EMPTY.
The tool used is ethtool:
ethtool -A eth1 autoneg off rx off tx off
[2]
Do you have any instructions on how to obtain and program Aquantia PHY firmware on our platforms? Do you know if there is a way to confirm what features have been enabled in a firmware release? e.g., USXGMII, XFI, SGMII support.
Check here: https://github.com/nxp-qoriq/qoriq-firmware-aquantia
[3]
Do you know if there is any extra step to enable the AQRate feature on AQ PHYs or that is the entire point of the PHY? It is always enabled?
This is a response to an older ticket:
“For the configuration in which the external phy (AQR) is connected to our MAC through XFI interface, the supported speed at MAC side is 10Gbps.(and this cannot be changed)
Our earlier code (I say earlier referring to the SDK 1703 and below, because the snippet of code updated by the customer seems to be from the SDK) made the following assumption:
-the interface type XFI uses a fixed speed that is 10Gbps. However, the implementation didn’t take into account that some phys -e.g AQR might support rate adaptation (through pause frames generated from the phy) such that at line side one could connect to a peer that had a 1Gbps phy.
According to the implementation, our driver removed the mode values advertised by the PHY to the system side, causing the failure of auto negotiation with a link partner lower that 10Gbps (e.g 1Gbps)
The WR proposed by SWI is ok in my opinion because what their change does is that it does not remove the modes advertised by the AQR phy.
In the upstream this fix is already present.
Now I will make an adjustment: I said above that “earlier code” had some incorrect assumptions. The same statement can be applied for the LSDK code: it does not support a phy with rate adaptation.
It means that only in upstream we can find something let’s say valid, for this particular case.
To understand my comments, see these patches:
https://github.com/torvalds/linux/commit/73a21fa817f0cc8022dc6226250a86bca727a56d
https://lkml.org/lkml/2020/2/10/633
“
[4]
I shared this with the CAS member.
" I can only state "boundedly undefined" behavior. Since we are XFI, we will always send data at 10Gbps. If the PHY negotiates a 1Gbps link side partner, it would want to avoid RX overrun. Hence, it sends PAUSE frames to the MAC (system side) to slow things down."