netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Santos <daniel.santos@pobox.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: "Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
	"René van Dorst" <opensource@vdorst.com>,
	sean.wang@mediatek.com, f.fainelli@gmail.com,
	davem@davemloft.net, matthias.bgg@gmail.com,
	vivien.didelot@gmail.com, frank-w@public-files.de,
	netdev@vger.kernel.org, linux-mediatek@lists.infradead.org,
	linux-mips@vger.kernel.org
Subject: Re: [PATCH RFC net-next 1/5] net: dsa: mt7530: Convert to PHYLINK API
Date: Thu, 27 Jun 2019 14:09:18 -0500	[thread overview]
Message-ID: <e469daa1-3e28-db9c-e29a-7f68cc676fda@pobox.com> (raw)
In-Reply-To: <20190625204148.GB27733@lunn.ch>



On 6/25/19 3:41 PM, Andrew Lunn wrote:
> On Tue, Jun 25, 2019 at 02:27:55PM -0500, Daniel Santos wrote:
>> On 6/25/19 2:02 PM, Andrew Lunn wrote:
>>>> But will there still be a mechanism to ignore link partner's advertising
>>>> and force these parameters?
>>> >From man 1 ethtool:
>>>
>>>        -a --show-pause
>>>               Queries the specified Ethernet device for pause parameter information.
>>>
>>>        -A --pause
>>>               Changes the pause parameters of the specified Ethernet device.
>>>
>>>            autoneg on|off
>>>                   Specifies whether pause autonegotiation should be enabled.
>>>
>>>            rx on|off
>>>                   Specifies whether RX pause should be enabled.
>>>
>>>            tx on|off
>>>                   Specifies whether TX pause should be enabled.
>>>
>>> You need to check the driver to see if it actually implements this
>>> ethtool call, but that is how it should be configured.
>>>
>>> 	Andrew
>>>
>> Thank you Andrew,
>>
>> So in this context, my question is the difference between "enabling" and
>> "forcing".  Here's that register for the mt7620 (which has an mt7530 on
>> its die): https://imgur.com/a/pTk0668  I believe this is also what René
>> is seeking clarity on?
> Lets start with normal operation. If the MAC supports pause or asym
> pause, it calls phy_support_sym_pause() or phy_support_asym_pause().
> phylib will then configure the PHY to advertise pause as appropriate.
> Once auto-neg has completed, the results of the negotiation are set in
> phydev. So phdev->pause and phydev->asym_pause. The MAC callback is
> then used to tell the MAC about the autoneg results. The MAC should be
> programmed using the values in phdev->pause and phydev->asym_pause.
>
> For ethtool, the MAC driver needs to implement .get_pauseparam and
> .set_pauseparam. The set_pauseparam needs to validate the settings,
> using phy_validate_pause(). If valid, phy_set_asym_pause() is used to
> tell the PHY about the new configuration. This will trigger a new
> auto-neg if auto-neg is enabled, and the results will be passed back
> in the usual way. If auto-neg is disabled, or pause auto-neg is
> disabled, the MAC should configure pause directly based on the
> settings passed.
>
> Looking at the data sheet page, you want FORCE_MODE_Pn set. You never
> want the MAC directly talking to the PHY. Bad things will happen.

So what exactly do you mean by the MAC directly talking to the PHY?  Do
you mean setting speed, duplex, etc. via the MAC registers instead of
via MDIO to the MII registers of the PHY?

> Then use FORCE_RX_FC_Pn and FORCE_TX_Pn to reflect phydev->pause and
> phydev->asym_pause.
>
> The same idea applies when using phylink.
>
>     Andrew

You're help is greatly appreciated here.  Admittedly, I'm also trying to
get this working in the now deprecated swconfig for a 3.18 kernel that's
in production.  In my code, I had just set the appropriate bits in both
the MAC and mii registers -- did I just shoot myself in the foot or only
toe or two? :)  I should probably start a separate thread for this. 
(And probably attempt to wrestle an mt7530 programmer's guide out of
MediaTek!)

Thanks,
Daniel

PS: I found a rather humorous quote from the mt7621 datasheet regarding
the MAC registers (at 0x3000 for port 0, 0x3100 for port 1, etc.):

    2.4 Link Status

    You can find MAC control register put at 0x3500 for MAC 5, and
    0x3600 for MAC 6. You can change
    MAC ability at this register. We would suggest don’t use the
    register 0x3000 to 0x3400. It may not
    work.

I'm not sure if this only applies to something in between the mt7621 and
it's internal mt7530 or not.

  parent reply	other threads:[~2019-06-27 19:11 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-24 14:52 [PATCH RFC net-next 0/5] net: dsa: MT7530: Convert to PHYLINK and add support for port 5 René van Dorst
2019-06-24 14:52 ` [PATCH RFC net-next 1/5] net: dsa: mt7530: Convert to PHYLINK API René van Dorst
2019-06-24 15:39   ` Russell King - ARM Linux admin
2019-06-25 11:31     ` René van Dorst
2019-06-25 12:10       ` Russell King - ARM Linux admin
2019-06-25 18:37         ` Daniel Santos
2019-06-25 19:02           ` Andrew Lunn
2019-06-25 19:27             ` Daniel Santos
2019-06-25 20:41               ` Andrew Lunn
2019-06-25 21:07                 ` René van Dorst
2019-06-25 21:21                 ` Russell King - ARM Linux admin
2019-06-27 19:09                 ` Daniel Santos [this message]
2019-06-27 19:28                   ` Andrew Lunn
2019-06-28  7:16                     ` Daniel Santos
2019-06-25 21:13             ` Russell King - ARM Linux admin
2019-06-25 20:24     ` Vladimir Oltean
2019-06-25 21:53       ` Russell King - ARM Linux admin
2019-06-25 22:14         ` Vladimir Oltean
2019-06-25 22:57           ` Russell King - ARM Linux admin
2019-06-25 23:10             ` Vladimir Oltean
2019-06-25 23:13               ` Vladimir Oltean
2019-06-26  1:52                 ` Andrew Lunn
2019-06-26  7:41               ` Russell King - ARM Linux admin
2019-06-26  8:46                 ` Vladimir Oltean
2019-06-26  9:04                   ` Russell King - ARM Linux admin
2019-06-25  0:58   ` Daniel Santos
2019-06-25 11:43     ` René van Dorst
2019-06-24 14:52 ` [PATCH RFC net-next 2/5] dt-bindings: net: dsa: mt7530: Add support for port 5 René van Dorst
2019-06-24 14:52 ` [PATCH RFC net-next 3/5] " René van Dorst
2019-06-24 14:52 ` [PATCH RFC net-next 4/5] dt-bindings: net: dsa: mt7530: Add mediatek,ephy-handle to isolate ext. phy René van Dorst
2019-06-24 21:56   ` Florian Fainelli
2019-06-25  9:30     ` René van Dorst
2019-06-25 19:16       ` Florian Fainelli
2019-06-24 14:52 ` [PATCH RFC net-next 5/5] net: dsa: mt7530: Add mediatek,ephy-handle to isolate external phy René van Dorst
2019-06-24 21:52   ` Andrew Lunn
2019-06-25  0:22     ` Daniel Santos
2019-06-25  8:24     ` René van Dorst

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=e469daa1-3e28-db9c-e29a-7f68cc676fda@pobox.com \
    --to=daniel.santos@pobox.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=frank-w@public-files.de \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux-mips@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=opensource@vdorst.com \
    --cc=sean.wang@mediatek.com \
    --cc=vivien.didelot@gmail.com \
    /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).