linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Doug Berger <opendmb@gmail.com>, "David S. Miller" <davem@davemloft.net>
Cc: bcm-kernel-feedback-list@broadcom.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH net 1/3] net: bcmgenet: use RGMII loopback for MAC reset
Date: Tue, 5 Nov 2019 19:45:02 -0800	[thread overview]
Message-ID: <5c4f7d6e-0e2d-86bc-d407-723cd3e8e8a2@gmail.com> (raw)
In-Reply-To: <1572980846-37707-2-git-send-email-opendmb@gmail.com>



On 11/5/2019 11:07 AM, Doug Berger wrote:
> As noted in commit 28c2d1a7a0bf ("net: bcmgenet: enable loopback
> during UniMAC sw_reset") the UniMAC must be clocked while sw_reset
> is asserted for its state machines to reset cleanly.
> 
> The transmit and receive clocks used by the UniMAC are derived from
> the signals used on its PHY interface. The bcmgenet MAC can be
> configured to work with different PHY interfaces including MII,
> GMII, RGMII, and Reverse MII on internal and external interfaces.
> Unfortunately for the UniMAC, when configured for MII the Tx clock
> is always driven from the PHY which places it outside of the direct
> control of the MAC.
> 
> The earlier commit enabled a local loopback mode within the UniMAC
> so that the receive clock would be derived from the transmit clock
> which addressed the observed issue with an external GPHY disabling
> it's Rx clock. However, when a Tx clock is not available this
> loopback is insufficient.
> 
> This commit implements a workaround that leverages the fact that
> the MAC can reliably generate all of its necessary clocking by
> enterring the external GPHY RGMII interface mode with the UniMAC in
> local loopback during the sw_reset interval. Unfortunately, this
> has the undesirable side efect of the RGMII GTXCLK signal being
> driven during the same window.
> 
> In most configurations this is a benign side effect as the signal
> is either not routed to a pin or is already expected to drive the
> pin. The one exception is when an external MII PHY is expected to
> drive the same pin with its TX_CLK output creating output driver
> contention.
> 
> This commit exploits the IEEE 802.3 clause 22 standard defined
> isolate mode to force an external MII PHY to present a high
> impedance on its TX_CLK output during the window to prevent any
> contention at the pin.
> 
> The MII interface is used internally with the 40nm internal EPHY
> which agressively disables its clocks for power savings leading to
> incomplete resets of the UniMAC and many instabilities observed
> over the years. The workaround of this commit is expected to put
> an end to those problems.
> 
> Fixes: 1c1008c793fa ("net: bcmgenet: add main driver file")
> Signed-off-by: Doug Berger <opendmb@gmail.com>

Acked-by: Florian Fainelli <f.fainelli@gmail.com>
-- 
Florian

  parent reply	other threads:[~2019-11-06  3:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 19:07 [PATCH net 0/3] net: bcmgenet: restore internal EPHY support (part 2) Doug Berger
2019-11-05 19:07 ` [PATCH net 1/3] net: bcmgenet: use RGMII loopback for MAC reset Doug Berger
2019-11-05 19:14   ` Scott Branden
2019-11-05 19:27     ` Doug Berger
2019-11-05 19:48       ` Scott Branden
2019-11-06  3:45   ` Florian Fainelli [this message]
2019-11-05 19:07 ` [PATCH net 2/3] Revert "net: bcmgenet: soft reset 40nm EPHYs before MAC init" Doug Berger
2019-11-06  3:45   ` Florian Fainelli
2019-11-05 19:07 ` [PATCH net 3/3] net: bcmgenet: reapply manual settings to the PHY Doug Berger
2019-11-06  3:45   ` Florian Fainelli
2019-11-06 19:05 ` [PATCH net 0/3] net: bcmgenet: restore internal EPHY support (part 2) David Miller

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=5c4f7d6e-0e2d-86bc-d407-723cd3e8e8a2@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=bcm-kernel-feedback-list@broadcom.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=opendmb@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).