netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: "Badel, Laurent" <LaurentBadel@eaton.com>
Cc: "davem@davemloft.net" <davem@davemloft.net>,
	"fugang.duan@nxp.com" <fugang.duan@nxp.com>,
	"kuba@kernel.org" <kuba@kernel.org>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
	"p.zabel@pengutronix.de" <p.zabel@pengutronix.de>,
	"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"robh+dt@kernel.org" <robh+dt@kernel.org>,
	"richard.leitner@skidata.com" <richard.leitner@skidata.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"Quette, Arnaud" <ArnaudQuette@Eaton.com>
Subject: Re: [PATCH net 0/4] Restore and fix PHY reset for SMSC LAN8720
Date: Thu, 29 Oct 2020 09:16:26 +0100	[thread overview]
Message-ID: <20201029081626.wtnhctobwvlhmfan@pengutronix.de> (raw)
In-Reply-To: <CY4PR1701MB1878B85B9E1C5B4FDCBA2860DF160@CY4PR1701MB1878.namprd17.prod.outlook.com>

Hi,

thanks for your patches :)

On 20-10-27 23:25, Badel, Laurent wrote:
> Subject: [PATCH net 0/4] Restore and fix PHY reset for SMSC LAN8720
> 
> Description:
> A recent patchset [1] added support in the SMSC PHY driver for managing
> the ref clock and therefore removed the PHY_RST_AFTER_CLK_EN flag for the
> LAN8720 chip. The ref clock is passed to the SMSC driver through a new
> property "clocks" in the device tree.
> 
> There appears to be two potential caveats:
> (i) Building kernel 5.9 without updating the DT with the "clocks"
> property for SMSC PHY, would break systems previously relying on the PHY
> reset workaround (SMSC driver cannot grab the ref clock, so it is still
> managed by FEC, but the PHY is not reset because PHY_RST_AFTER_CLK_EN is
> not set). This may lead to occasional loss of ethernet connectivity in
> these systems, that is difficult to debug.

IMHO reyling on PHY_RST_AFTER_CLK_EN was broken since the day of adding
this feature because:

1st) Each host driver needs to call the phy-reset logic. So this isn't a
     fix for all hosts using a LAN8720 phy.
2st) It interacts realy bad with the phy state machine. Only the state
     machine should be able to do this.

Why can't you add the clock?

> (ii) This defeats the purpose of a previous commit [2] that disabled the
> ref clock for power saving reasons. If a ref clock for the PHY is
> specified in DT, the SMSC driver will keep it always on (confirmed with 
> scope).

NACK, the clock provider can be any clock. This has nothing to do with
the FEC clocks. The FEC _can_ be used as clock provider.

> While this removes the need for additional PHY resets (only a 
> single reset is needed after power up), this prevents the FEC from saving
> power by disabling the refclk. Since there may be use cases where one is
> interested in saving power,

You can't just turn off the clock for the LAN8720 because of the phy
internal state machine. The state machine gets confused if the clock is
turned off/on randomly.

> keep this option available when no ref clock
> is specified for the PHY, by fixing issues with the PHY reset.

IMHO pulling the reset line everytime has a few disadvantages:
 - You need to ensure that the strapping pins are correct and
 - You need to ensure that the reset logic including the reset delays
   are keeped.

> Main changes proposed to address this:
> (a) Restore PHY_RST_AFTER_CLK_EN for LAN8720, but explicitly clear it if
> the SMSC driver succeeds in retrieving the ref clock.

IMHO NACK since this was the wrong approach.

> (b) Fix phy_reset_after_clk_enable() to work in interrupt mode, by
> re-configuring the PHY registers after reset.
> 
> Tests: against net tree 5.9, including allyes/no/modconfig. 10 pieces of
> an iMX28-EVK-based board were tested, 3 of which were found to exhibit
> issues when the "clocks" property was left unset. Issues were fixed by
> the present patchset.

All iMX machines are now DT-based why can't you just add the correct
clock provider?

Regards,
  Marco

  parent reply	other threads:[~2020-10-29  8:17 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 23:25 [PATCH net 0/4] Restore and fix PHY reset for SMSC LAN8720 Badel, Laurent
2020-10-28 23:10 ` Jakub Kicinski
2020-11-02 15:24   ` [EXTERNAL] " Badel, Laurent
2020-10-29  8:16 ` Marco Felsch [this message]
2020-11-04 12:08   ` Badel, Laurent
2020-11-04 13:11     ` Andrew Lunn
2020-11-04 13:14       ` Badel, Laurent

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=20201029081626.wtnhctobwvlhmfan@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=ArnaudQuette@Eaton.com \
    --cc=LaurentBadel@eaton.com \
    --cc=andrew@lunn.ch \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=fugang.duan@nxp.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=p.zabel@pengutronix.de \
    --cc=richard.leitner@skidata.com \
    --cc=robh+dt@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).