linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Florian Fainelli <f.fainelli@gmail.com>, <andrew@lunn.ch>,
	<hkallweit1@gmail.com>, <bunk@kernel.org>
Cc: <netdev@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <grygorii.strashko@ti.com>
Subject: Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
Date: Fri, 31 Jan 2020 13:14:44 -0600	[thread overview]
Message-ID: <516ae353-e068-fe5e-768f-52308ef670a9@ti.com> (raw)
In-Reply-To: <5c956a5a-cd83-f290-9995-6ea35383f5f0@gmail.com>

Florian

On 1/31/20 12:42 PM, Florian Fainelli wrote:
> On 1/31/20 10:29 AM, Dan Murphy wrote:
>> Florian
>>
>> On 1/31/20 11:49 AM, Florian Fainelli wrote:
>>> On 1/31/20 7:11 AM, 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.
>>> 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

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.

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


>>>    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.

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


  reply	other threads:[~2020-01-31 19:18 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-31 15:11 [PATCH net-master 0/1] DP83867 Speed optimization feature Dan Murphy
2020-01-31 15:11 ` [PATCH net-master 1/1] net: phy: dp83867: Add speed " Dan Murphy
2020-01-31 17:10   ` Jakub Kicinski
2020-01-31 17:14     ` Dan Murphy
2020-01-31 18:11       ` Jakub Kicinski
2020-01-31 18:36         ` Dan Murphy
2020-01-31 17:49   ` Florian Fainelli
2020-01-31 18:29     ` Dan Murphy
2020-01-31 18:42       ` Florian Fainelli
2020-01-31 19:14         ` Dan Murphy [this message]
2020-01-31 19:29           ` Florian Fainelli
2020-01-31 19:54             ` Dan Murphy
2020-01-31 20:02               ` Florian Fainelli
2020-01-31 20:10                 ` Dan Murphy
2020-01-31 20:56   ` Heiner Kallweit
2020-02-01  1:30     ` Dan Murphy
2020-02-01  4:57       ` Florian Fainelli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=516ae353-e068-fe5e-768f-52308ef670a9@ti.com \
    --to=dmurphy@ti.com \
    --cc=andrew@lunn.ch \
    --cc=bunk@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).