On 1/31/20 11:14 AM, Dan Murphy wrote:

Florian

On 1/31/20 12:42 PM, Florian Fainelli wrote:

quoted

On 1/31/20 10:29 AM, Dan Murphy wrote:

quoted

Florian

On 1/31/20 11:49 AM, Florian Fainelli wrote:

quoted

On 1/31/20 7:11 AM, Dan Murphy wrote:

quoted

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.

OK, but why and how does that optimization work exactly?

I described this in the cover letter.  And it is explained in the data
sheet Section 8.4.6.6

Sorry I complete missed that and just focused on the patch, you should
consider not providing a cover letter for a single patch, and especially
not when the cover letter contains more information than the patch
commit message itself.

Sorry I usually give a cover letter to all my network related patches.

Unless I misinterpreted David on his reply to me about cover letters.

https://www.spinics.net/lists/netdev/msg617575.html

This was a 2 patches series, for which a cover letter is mandatory:

but for single patches, there really is no need, and having to replicate
the same information in two places is just error prone.

And I seemed to have missed David on the --cc list so I will add him for
v2.

I was also asked not to provide the same information in the cover letter
and the commit message.

The cover letter is meant to provide some background about choices you
have made, or how to merge the patches, or their dependencies, and
describe the changes in a big picture. The patches themselves are
supposed to be comprehensive.

Either way I am ok with not providing a cover letter and updating the
commit message with more information.

quoted

quoted

quoted

   Departing from
the BMSR reads means you possibly are going to introduce bugs and/or
incomplete information. For instance, you set phydev->pause and
phydev->asym_pause to 0 now, is there no way to extract what the link
partner has advertised?

I was using the marvel.c as my template as it appears to have a separate
status register as well.

Instead of setting those bits in the call back I can call the
genphy_read_status then override the duplex and speed based on the
physts register like below.  This way link status and pause values can
be updated and then we can update the speed and duplex settings.

       ret = genphy_read_status(phydev);
     if (ret)
         return ret;

     if (status < 0)
         return status;

     if (status & DP83867_PHYSTS_DUPLEX)
         phydev->duplex = DUPLEX_FULL;
     else
         phydev->duplex = DUPLEX_HALF;

     if (status & DP83867_PHYSTS_1000)
         phydev->speed = SPEED_1000;
     else if (status & DP83867_PHYSTS_100)
         phydev->speed = SPEED_100;
     else
         phydev->speed = SPEED_10;

OK, but what if they disagree, are they consistently latched with
respect to one another?

Well in parsing through the code for genphy read status when auto
negotiation is set the phydev structure appears to be setup per what has
been configured.  I did not see any reading of speed or duplex when auto
neg is set it is just taking the LPA register. But I am probably not
right here.  So we and our customers found that the phy was always
reporting a 1Gbps connection when the 4 wire cable connected when using
genphy_read_status.  This PHYSTS register provides a single location
within the register set for quick access to commonly accessed
information.

That is the kind of information that you want to put in the commit
message, and that sounds like a Fix more than a feature to me. If the
BMSR is not reflecting the correct speed, clearly something is not quite
good. You may also consider reflecting whether downshift was in action
and that led to reducing the speed, something like
m88e1011_link_change_notify() does.

The PHYSTS register from the chip is what the PHY negotiated with the LP.

[   10.404355] dp83867_read_status:STS is 0x6C02  - PHYSTS register
reporting a 100Mbps speed with a 4 wire cable
[   10.413450] dp83867_read_status:BMCR is 0x1140  - BMCR is configured
for a 1Gbps connection with a 4 wire cable.  But the speed should be
100Mbps.
[   10.417906] dp83867_read_status:BMSR is 0x796D  - BMSR which just
states what the device is capable of doing but does not report the
actual speed or duplex mode.

So unless I missed some code in the phy_device or phy_core this is the
only way I could see to report the correct negotiated speed and duplex
mode.

Dan

-- 
Florian