Re: [PATCH net-next v2] net: phy: dp83867: Add speed optimization feature

From: Dan Murphy
Date: Thu Feb 06 2020 - 18:28:06 EST


Heiner

On 2/6/20 5:04 PM, Heiner Kallweit wrote:
On 06.02.2020 23:36, Dan Murphy wrote:
Heiner

On 2/6/20 4:28 PM, Heiner Kallweit wrote:
On 06.02.2020 23:13, Dan Murphy wrote:
Heiner

On 2/5/20 3:16 PM, Heiner Kallweit wrote:
On 04.02.2020 19:13, Dan Murphy wrote:
Set the speed optimization bit on the DP83867 PHY.
This feature can also be strapped on the 64 pin PHY devices
but the 48 pin devices do not have the strap pin available to enable
this feature in the hardware. PHY team suggests to have this bit set.

With this bit set the PHY will auto negotiate and report the link
parameters in the PHYSTS register. This register provides a single
location within the register set for quick access to commonly accessed
information.

In this case when auto negotiation is on the PHY core reads the bits
that have been configured or if auto negotiation is off the PHY core
reads the BMCR register and sets the phydev parameters accordingly.

This Giga bit PHY can throttle the speed to 100Mbps or 10Mbps to accomodate a
4-wire cable. If this should occur the PHYSTS register contains the
current negotiated speed and duplex mode.

In overriding the genphy_read_status the dp83867_read_status will do a
genphy_read_status to setup the LP and pause bits. And then the PHYSTS
register is read and the phydev speed and duplex mode settings are
updated.

Signed-off-by: Dan Murphy <dmurphy@xxxxxx>
---
v2 - Updated read status to call genphy_read_status first, added link_change
callback to notify of speed change and use phy_set_bits - https://lore.kernel.org/patchwork/patch/1188348/

As stated in the first review, it would be appreciated if you implement
also the downshift tunable. This could be a separate patch in this series.
Most of the implementation would be boilerplate code.
I looked at this today and there are no registers that allow tuning the downshift attempts. There is only a RO register that tells you how many attempts it took to achieve a link. So at the very least we could put in the get_tunable but there will be no set.

The get operation for the downshift tunable should return after how many failed
attempts the PHY starts a downshift. This doesn't match with your description of
this register, so yes: Implementing the tunable for this PHY doesn't make sense.
True. This register is only going to return 1,2,4 and 8. And it is defaulted to 4 attempts.
However this register may be useful in the link_change_notify() callback to
figure out whether a downshift happened, to trigger the info message you had in
your first version.
Thats a good idea but.. The register is defaulted to always report 4 attempts were made. It never reports 0 attempts so we would never know the truth behind the reporting. Kinda like matching the speeds.

I just had a brief look at the datasheet here: http://www.ti.com/lit/ds/symlink/dp83867ir.pdf
It says: The number of failed link attempts before falling back to 100-M operation is configurable. (p.45)
Description of SPEED_OPT_ATTEMPT_CNT in CFG2 says "select attempt count", so it sounds like it's
an RW register. It's marked as RO however, maybe it's a typo in the datasheet.
Did you test whether register is writable?

Yes I did and it was a no go. It is definitely a RO. I will complain to the HW team and get it straightened out. We have time before net-next opens


Last but not least this register is exactly what's needed for the downshift tunable.

Checking whether a downshift occurred should be possible by reading SPEED_OPT_EVENT_INT in ISR.
In interrupt mode however this may require a custom interrupt handler (implementation of
handle_interrupt callback).

Yes the HW team did say R13b5 could be checked but after thinking about it the issue with that is that is a clear on read register so other status would be lost. There could be a race condition between the interrupt handler and the link notification change to be able to indicate whether the downshift happened or not.

Same with polling mode can we be guaranteed that the status would be updated before the link change was called?

Dan