* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
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 17:49 ` Florian Fainelli
2020-01-31 20:56 ` Heiner Kallweit
2 siblings, 1 reply; 17+ messages in thread
From: Jakub Kicinski @ 2020-01-31 17:10 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, bunk, netdev, devicetree,
linux-kernel, grygorii.strashko
On Fri, 31 Jan 2020 09:11:10 -0600, 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 and not in the BMCR. So we need to
> over ride the genphy_read_status with a DP83867 specific read status.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
While we wait for the PHY folk to take a look, could you please
provide a Fixes tag?
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 17:10 ` Jakub Kicinski
@ 2020-01-31 17:14 ` Dan Murphy
2020-01-31 18:11 ` Jakub Kicinski
0 siblings, 1 reply; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 17:14 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew, f.fainelli, hkallweit1, bunk, netdev, devicetree,
linux-kernel, grygorii.strashko
Jakub
On 1/31/20 11:10 AM, Jakub Kicinski wrote:
> On Fri, 31 Jan 2020 09:11:10 -0600, 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 and not in the BMCR. So we need to
>> over ride the genphy_read_status with a DP83867 specific read status.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> While we wait for the PHY folk to take a look, could you please
> provide a Fixes tag?
Hmm. This is not a bug fix though this is a new feature being added.
Not sure what it would be fixing.
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 17:14 ` Dan Murphy
@ 2020-01-31 18:11 ` Jakub Kicinski
2020-01-31 18:36 ` Dan Murphy
0 siblings, 1 reply; 17+ messages in thread
From: Jakub Kicinski @ 2020-01-31 18:11 UTC (permalink / raw)
To: Dan Murphy
Cc: andrew, f.fainelli, hkallweit1, bunk, netdev, devicetree,
linux-kernel, grygorii.strashko
On Fri, 31 Jan 2020 11:14:05 -0600, Dan Murphy wrote:
> On 1/31/20 11:10 AM, Jakub Kicinski wrote:
> > While we wait for the PHY folk to take a look, could you please
> > provide a Fixes tag?
>
> Hmm. This is not a bug fix though this is a new feature being added.
>
> Not sure what it would be fixing.
I see, you target the patch at net which is for fixes, so I
misinterpreted this:
> 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.
as you fixing 48 devices or such.
So please correct the tree to net-next and since net-next is now closed:
http://vger.kernel.org/~davem/net-next.html
only post as RFC until net-next opens back up.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 18:11 ` Jakub Kicinski
@ 2020-01-31 18:36 ` Dan Murphy
0 siblings, 0 replies; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 18:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: andrew, f.fainelli, hkallweit1, bunk, netdev, devicetree,
linux-kernel, grygorii.strashko
Jakob
On 1/31/20 12:11 PM, Jakub Kicinski wrote:
> On Fri, 31 Jan 2020 11:14:05 -0600, Dan Murphy wrote:
>> On 1/31/20 11:10 AM, Jakub Kicinski wrote:
>>> While we wait for the PHY folk to take a look, could you please
>>> provide a Fixes tag?
>> Hmm. This is not a bug fix though this is a new feature being added.
>>
>> Not sure what it would be fixing.
> I see, you target the patch at net which is for fixes, so I
> misinterpreted this:
My fault I will have a v2 so I will rebase on top of net-next.
>> 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.
> as you fixing 48 devices or such.
Not really fixing them just enabling them to use this feature.
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
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:49 ` Florian Fainelli
2020-01-31 18:29 ` Dan Murphy
2020-01-31 20:56 ` Heiner Kallweit
2 siblings, 1 reply; 17+ messages in thread
From: Florian Fainelli @ 2020-01-31 17:49 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
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? 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?
>
> With this bit set the PHY will auto negotiate and report the link
> parameters in the PHYSTS register and not in the BMCR.
That should be BMSR, the BMCR is about control, not status.
> So we need to
> over ride the genphy_read_status with a DP83867 specific read status.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> drivers/net/phy/dp83867.c | 48 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 967f57ed0b65..695aaf4f942f 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -21,6 +21,7 @@
> #define DP83867_DEVADDR 0x1f
>
> #define MII_DP83867_PHYCTRL 0x10
> +#define MII_DP83867_PHYSTS 0x11
> #define MII_DP83867_MICR 0x12
> #define MII_DP83867_ISR 0x13
> #define DP83867_CFG2 0x14
> @@ -118,6 +119,15 @@
> #define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK (0x1f << 8)
> #define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8
>
> +/* PHY STS bits */
> +#define DP83867_PHYSTS_1000 BIT(15)
> +#define DP83867_PHYSTS_100 BIT(14)
> +#define DP83867_PHYSTS_DUPLEX BIT(13)
> +#define DP83867_PHYSTS_LINK BIT(10)
> +
> +/* CFG2 bits */
> +#define DP83867_SPEED_OPTIMIZED_EN (BIT(8) | BIT(9))
> +
> /* CFG3 bits */
> #define DP83867_CFG3_INT_OE BIT(7)
> #define DP83867_CFG3_ROBUST_AUTO_MDIX BIT(9)
> @@ -287,6 +297,36 @@ static int dp83867_config_intr(struct phy_device *phydev)
> return phy_write(phydev, MII_DP83867_MICR, micr_status);
> }
>
> +static int dp83867_read_status(struct phy_device *phydev)
> +{
> + int status = phy_read(phydev, MII_DP83867_PHYSTS);
> +
> + 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;
> +
> + if (status & DP83867_PHYSTS_LINK)
> + phydev->link = 1;
> + else
> + phydev->link = 0;
> +
> + phydev->pause = 0;
> + phydev->asym_pause = 0;
> +
> + return 0;
> +}
> +
> static int dp83867_config_port_mirroring(struct phy_device *phydev)
> {
> struct dp83867_private *dp83867 =
> @@ -467,6 +507,12 @@ static int dp83867_config_init(struct phy_device *phydev)
> int ret, val, bs;
> u16 delay;
>
> + /* Force speed optimization for the PHY even if it strapped */
> + ret = phy_modify(phydev, DP83867_CFG2, DP83867_SPEED_OPTIMIZED_EN,
> + DP83867_SPEED_OPTIMIZED_EN);
> + if (ret)
> + return ret;
> +
> ret = dp83867_verify_rgmii_cfg(phydev);
> if (ret)
> return ret;
> @@ -655,6 +701,8 @@ static struct phy_driver dp83867_driver[] = {
> .config_init = dp83867_config_init,
> .soft_reset = dp83867_phy_reset,
>
> + .read_status = dp83867_read_status,
> +
> .get_wol = dp83867_get_wol,
> .set_wol = dp83867_set_wol,
>
>
--
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 17:49 ` Florian Fainelli
@ 2020-01-31 18:29 ` Dan Murphy
2020-01-31 18:42 ` Florian Fainelli
0 siblings, 1 reply; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 18:29 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
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
> 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;
>> With this bit set the PHY will auto negotiate and report the link
>> parameters in the PHYSTS register and not in the BMCR.
> That should be BMSR, the BMCR is about control, not status.
OK.
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 18:29 ` Dan Murphy
@ 2020-01-31 18:42 ` Florian Fainelli
2020-01-31 19:14 ` Dan Murphy
0 siblings, 1 reply; 17+ messages in thread
From: Florian Fainelli @ 2020-01-31 18:42 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
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.
>
>> 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?
>
>>> With this bit set the PHY will auto negotiate and report the link
>>> parameters in the PHYSTS register and not in the BMCR.
>> That should be BMSR, the BMCR is about control, not status.
>
> OK.
>
> Dan
>
--
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 18:42 ` Florian Fainelli
@ 2020-01-31 19:14 ` Dan Murphy
2020-01-31 19:29 ` Florian Fainelli
0 siblings, 1 reply; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 19:14 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 19:14 ` Dan Murphy
@ 2020-01-31 19:29 ` Florian Fainelli
2020-01-31 19:54 ` Dan Murphy
0 siblings, 1 reply; 17+ messages in thread
From: Florian Fainelli @ 2020-01-31 19:29 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
On 1/31/20 11:14 AM, Dan Murphy wrote:
> 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
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.
>
>
>>>> 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
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 19:29 ` Florian Fainelli
@ 2020-01-31 19:54 ` Dan Murphy
2020-01-31 20:02 ` Florian Fainelli
0 siblings, 1 reply; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 19:54 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
Florian
On 1/31/20 1:29 PM, Florian Fainelli wrote:
> On 1/31/20 11:14 AM, Dan Murphy wrote:
>> 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
> 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.
As always thank you for the guidance. I will update the commit with
better information and remove the cover letter.
>
>> 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.
> 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.
But what is it fixing? When the driver was originally submitted it was
meant to be a Giga bit PHY. No requirement for any connection less then
1Gbps. Now we have a customer who wants to use this feature and they
want it upstreamed. (YAY for them pushing upstream).
Do I reference my original commit? Because I am actually flipping the
bits to turn it on as well only way this was a fix is if the user had
the feature strapped to on. But to date we have not had any requests
for this support.
So then it would be ok to do a genphy_read_status and then override the
speed and duplex mode from the PHYSTS register?
I don't think that the link change notification is needed. The speed
should not change once the cable is plugged in and the speed is negotiated.
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 19:54 ` Dan Murphy
@ 2020-01-31 20:02 ` Florian Fainelli
2020-01-31 20:10 ` Dan Murphy
0 siblings, 1 reply; 17+ messages in thread
From: Florian Fainelli @ 2020-01-31 20:02 UTC (permalink / raw)
To: Dan Murphy, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
On 1/31/20 11:54 AM, Dan Murphy wrote:
> Florian
>
> On 1/31/20 1:29 PM, Florian Fainelli wrote:
>> On 1/31/20 11:14 AM, Dan Murphy wrote:
>>> 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
>> 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.
>
> As always thank you for the guidance. I will update the commit with
> better information and remove the cover letter.
No worries, every subsystem has its own rules, because why not :)
>
>
>>
>>> 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.
>> 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.
>
> But what is it fixing? When the driver was originally submitted it was
> meant to be a Giga bit PHY. No requirement for any connection less then
> 1Gbps. Now we have a customer who wants to use this feature and they
> want it upstreamed. (YAY for them pushing upstream).
>
> Do I reference my original commit? Because I am actually flipping the
> bits to turn it on as well only way this was a fix is if the user had
> the feature strapped to on. But to date we have not had any requests
> for this support.
>
> So then it would be ok to do a genphy_read_status and then override the
> speed and duplex mode from the PHYSTS register?
I would think so yes, especially if that is needed for reporting the
actual link speed that ended up being negotiated, and not the one that
the link was initially trained at. That assumes I understand that the
problem is that you advertise and want Gigabit, but because of a 4-wire
cable being plugged in, you ended up at 100Mbits/sec.
>
> I don't think that the link change notification is needed. The speed
> should not change once the cable is plugged in and the speed is negotiated.
The link change notification is just to signal to the user that the
speed may have been reduced due to downshifting, which would/could
happen with 4-wires instead of the expected 8-wires. Certainly not
strictly necessary right now, I agree.
--
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 20:02 ` Florian Fainelli
@ 2020-01-31 20:10 ` Dan Murphy
0 siblings, 0 replies; 17+ messages in thread
From: Dan Murphy @ 2020-01-31 20:10 UTC (permalink / raw)
To: Florian Fainelli, andrew, hkallweit1, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
Florian
On 1/31/20 2:02 PM, Florian Fainelli wrote:
> On 1/31/20 11:54 AM, Dan Murphy wrote:
> <snip>
>> So then it would be ok to do a genphy_read_status and then override the
>> speed and duplex mode from the PHYSTS register?
> I would think so yes, especially if that is needed for reporting the
> actual link speed that ended up being negotiated, and not the one that
> the link was initially trained at. That assumes I understand that the
> problem is that you advertise and want Gigabit, but because of a 4-wire
> cable being plugged in, you ended up at 100Mbits/sec.
Exactly.
>> I don't think that the link change notification is needed. The speed
>> should not change once the cable is plugged in and the speed is negotiated.
> The link change notification is just to signal to the user that the
> speed may have been reduced due to downshifting, which would/could
> happen with 4-wires instead of the expected 8-wires. Certainly not
> strictly necessary right now, I agree.
Ack
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
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:49 ` Florian Fainelli
@ 2020-01-31 20:56 ` Heiner Kallweit
2020-02-01 1:30 ` Dan Murphy
2 siblings, 1 reply; 17+ messages in thread
From: Heiner Kallweit @ 2020-01-31 20:56 UTC (permalink / raw)
To: Dan Murphy, andrew, f.fainelli, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
On 31.01.2020 16:11, 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.
>
It's ok to enable downshift by default, however it would be good to
make it configurable. Best implement the downshift tunable, you can
use the Marvell PHY driver as reference.
Can the number of attempts until downshifts happens be configured?
> With this bit set the PHY will auto negotiate and report the link
> parameters in the PHYSTS register and not in the BMCR. So we need to
> over ride the genphy_read_status with a DP83867 specific read status.
>
> Signed-off-by: Dan Murphy <dmurphy@ti.com>
> ---
> drivers/net/phy/dp83867.c | 48 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 48 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 967f57ed0b65..695aaf4f942f 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -21,6 +21,7 @@
> #define DP83867_DEVADDR 0x1f
>
> #define MII_DP83867_PHYCTRL 0x10
> +#define MII_DP83867_PHYSTS 0x11
> #define MII_DP83867_MICR 0x12
> #define MII_DP83867_ISR 0x13
> #define DP83867_CFG2 0x14
> @@ -118,6 +119,15 @@
> #define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK (0x1f << 8)
> #define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8
>
> +/* PHY STS bits */
> +#define DP83867_PHYSTS_1000 BIT(15)
> +#define DP83867_PHYSTS_100 BIT(14)
> +#define DP83867_PHYSTS_DUPLEX BIT(13)
> +#define DP83867_PHYSTS_LINK BIT(10)
> +
> +/* CFG2 bits */
> +#define DP83867_SPEED_OPTIMIZED_EN (BIT(8) | BIT(9))
> +
> /* CFG3 bits */
> #define DP83867_CFG3_INT_OE BIT(7)
> #define DP83867_CFG3_ROBUST_AUTO_MDIX BIT(9)
> @@ -287,6 +297,36 @@ static int dp83867_config_intr(struct phy_device *phydev)
> return phy_write(phydev, MII_DP83867_MICR, micr_status);
> }
>
> +static int dp83867_read_status(struct phy_device *phydev)
> +{
> + int status = phy_read(phydev, MII_DP83867_PHYSTS);
> +
> + 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;
> +
> + if (status & DP83867_PHYSTS_LINK)
> + phydev->link = 1;
> + else
> + phydev->link = 0;
> +
> + phydev->pause = 0;
> + phydev->asym_pause = 0;
> +
> + return 0;
> +}
> +
> static int dp83867_config_port_mirroring(struct phy_device *phydev)
> {
> struct dp83867_private *dp83867 =
> @@ -467,6 +507,12 @@ static int dp83867_config_init(struct phy_device *phydev)
> int ret, val, bs;
> u16 delay;
>
> + /* Force speed optimization for the PHY even if it strapped */
> + ret = phy_modify(phydev, DP83867_CFG2, DP83867_SPEED_OPTIMIZED_EN,
> + DP83867_SPEED_OPTIMIZED_EN);
Here phy_set_bits() would be easier.
> + if (ret)
> + return ret;
> +
> ret = dp83867_verify_rgmii_cfg(phydev);
> if (ret)
> return ret;
> @@ -655,6 +701,8 @@ static struct phy_driver dp83867_driver[] = {
> .config_init = dp83867_config_init,
> .soft_reset = dp83867_phy_reset,
>
> + .read_status = dp83867_read_status,
> +
> .get_wol = dp83867_get_wol,
> .set_wol = dp83867_set_wol,
>
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-01-31 20:56 ` Heiner Kallweit
@ 2020-02-01 1:30 ` Dan Murphy
2020-02-01 4:57 ` Florian Fainelli
0 siblings, 1 reply; 17+ messages in thread
From: Dan Murphy @ 2020-02-01 1:30 UTC (permalink / raw)
To: Heiner Kallweit, andrew, f.fainelli, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
Heiner
On 1/31/20 2:56 PM, Heiner Kallweit wrote:
> On 31.01.2020 16:11, 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.
>>
> It's ok to enable downshift by default, however it would be good to
> make it configurable. Best implement the downshift tunable, you can
> use the Marvell PHY driver as reference.
> Can the number of attempts until downshifts happens be configured?
Yes we can tune the number of attempts it makes to negotiate 1000Mbps
before enabling the speed optimization. But why would we need to
configure the number of attempts currently it is defaulted to 4. Is
there a use case for this level of configurability?
>
>> With this bit set the PHY will auto negotiate and report the link
>> parameters in the PHYSTS register and not in the BMCR. So we need to
>> over ride the genphy_read_status with a DP83867 specific read status.
>>
>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>> ---
>> drivers/net/phy/dp83867.c | 48 +++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
>> index 967f57ed0b65..695aaf4f942f 100644
>> --- a/drivers/net/phy/dp83867.c
>> +++ b/drivers/net/phy/dp83867.c
>> @@ -21,6 +21,7 @@
>> #define DP83867_DEVADDR 0x1f
>>
>> #define MII_DP83867_PHYCTRL 0x10
>> +#define MII_DP83867_PHYSTS 0x11
>> #define MII_DP83867_MICR 0x12
>> #define MII_DP83867_ISR 0x13
>> #define DP83867_CFG2 0x14
>> @@ -118,6 +119,15 @@
>> #define DP83867_IO_MUX_CFG_CLK_O_SEL_MASK (0x1f << 8)
>> #define DP83867_IO_MUX_CFG_CLK_O_SEL_SHIFT 8
>>
>> +/* PHY STS bits */
>> +#define DP83867_PHYSTS_1000 BIT(15)
>> +#define DP83867_PHYSTS_100 BIT(14)
>> +#define DP83867_PHYSTS_DUPLEX BIT(13)
>> +#define DP83867_PHYSTS_LINK BIT(10)
>> +
>> +/* CFG2 bits */
>> +#define DP83867_SPEED_OPTIMIZED_EN (BIT(8) | BIT(9))
>> +
>> /* CFG3 bits */
>> #define DP83867_CFG3_INT_OE BIT(7)
>> #define DP83867_CFG3_ROBUST_AUTO_MDIX BIT(9)
>> @@ -287,6 +297,36 @@ static int dp83867_config_intr(struct phy_device *phydev)
>> return phy_write(phydev, MII_DP83867_MICR, micr_status);
>> }
>>
>> +static int dp83867_read_status(struct phy_device *phydev)
>> +{
>> + int status = phy_read(phydev, MII_DP83867_PHYSTS);
>> +
>> + 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;
>> +
>> + if (status & DP83867_PHYSTS_LINK)
>> + phydev->link = 1;
>> + else
>> + phydev->link = 0;
>> +
>> + phydev->pause = 0;
>> + phydev->asym_pause = 0;
>> +
>> + return 0;
>> +}
>> +
>> static int dp83867_config_port_mirroring(struct phy_device *phydev)
>> {
>> struct dp83867_private *dp83867 =
>> @@ -467,6 +507,12 @@ static int dp83867_config_init(struct phy_device *phydev)
>> int ret, val, bs;
>> u16 delay;
>>
>> + /* Force speed optimization for the PHY even if it strapped */
>> + ret = phy_modify(phydev, DP83867_CFG2, DP83867_SPEED_OPTIMIZED_EN,
>> + DP83867_SPEED_OPTIMIZED_EN);
> Here phy_set_bits() would be easier.
Ack
Dan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [PATCH net-master 1/1] net: phy: dp83867: Add speed optimization feature
2020-02-01 1:30 ` Dan Murphy
@ 2020-02-01 4:57 ` Florian Fainelli
0 siblings, 0 replies; 17+ messages in thread
From: Florian Fainelli @ 2020-02-01 4:57 UTC (permalink / raw)
To: Dan Murphy, Heiner Kallweit, andrew, bunk
Cc: netdev, devicetree, linux-kernel, grygorii.strashko
On 1/31/2020 5:30 PM, Dan Murphy wrote:
> Heiner
>
> On 1/31/20 2:56 PM, Heiner Kallweit wrote:
>> On 31.01.2020 16:11, 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.
>>>
>> It's ok to enable downshift by default, however it would be good to
>> make it configurable. Best implement the downshift tunable, you can
>> use the Marvell PHY driver as reference.
>> Can the number of attempts until downshifts happens be configured?
>
> Yes we can tune the number of attempts it makes to negotiate 1000Mbps
> before enabling the speed optimization. But why would we need to
> configure the number of attempts currently it is defaulted to 4. Is
> there a use case for this level of configurability?
Some customers may prefer a fast(er) link re-negotiation once they know
the cabling is faulty or sub-optimal. The default is usually fine, and
if you want to support the downshift ethtool tunable when net-next opens
back up, that would be a welcome addition.
--
Florian
^ permalink raw reply [flat|nested] 17+ messages in thread