From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
To: Arseny Solokha <asolokha@kb.kras.ru>
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>,
Ioana Ciornei <ioana.ciornei@nxp.com>,
Andrew Lunn <andrew@lunn.ch>,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH 2/2] net: phylink: don't start and stop SGMII PHYs in SFP modules twice
Date: Wed, 24 Jul 2019 10:01:39 +0100 [thread overview]
Message-ID: <20190724090139.GG1330@shell.armlinux.org.uk> (raw)
In-Reply-To: <20190723151702.14430-3-asolokha@kb.kras.ru>
On Tue, Jul 23, 2019 at 10:17:02PM +0700, Arseny Solokha wrote:
> SFP modules connected using the SGMII interface have their own PHYs which
> are handled by the struct phylink's phydev field. After commit ce0aa27ff3f6
> ("sfp: add sfp-bus to bridge between network devices and sfp cages") an
> sfp-bus attached to the same phylink also gets control over a PHY in an SFP
> module which is actually the same PHY managed by phylink itself. This
> results in WARNs during network interface bringup and shutdown when a
> copper SFP module is connected, as phy_start() and phy_stop() are called
> twice in a row for the same phy_device:
>...
> So, skip explicit calls to phy_start() and phy_stop() when phylink has just
> enabled or disabled an attached SFP module.
I'd prefer if we re-ordered these so phy_start() happens before
sfp_upstream_start() and the reverse for the stop calls.
pl->phydev won't be set at these points, so the calls will be no-ops.
(The reason is when we support mac--phy--sfp setups, having the
phy_start() and phy_stop() here are still necessary.)
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
next prev parent reply other threads:[~2019-07-24 9:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-23 15:17 [RFC PATCH 0/2] convert gianfar to phylink Arseny Solokha
2019-07-23 15:17 ` [RFC PATCH 1/2] gianfar: convert " Arseny Solokha
2019-07-23 16:07 ` Claudiu Manoil
2019-07-24 7:36 ` Arseny Solokha
2019-07-24 8:19 ` Russell King - ARM Linux admin
2019-07-29 23:39 ` Vladimir Oltean
2019-07-30 10:23 ` Russell King - ARM Linux admin
2019-08-24 12:49 ` Vladimir Oltean
2019-07-30 14:40 ` Arseny Solokha
2019-08-24 15:21 ` Vladimir Oltean
2019-08-28 15:20 ` Vladimir Oltean
2019-09-04 13:52 ` [PATCH 0/4] gianfar: some assorted cleanup Arseny Solokha
2019-09-04 13:52 ` [PATCH 1/4] gianfar: remove forward declarations Arseny Solokha
2019-09-04 13:52 ` [PATCH 2/4] gianfar: make five functions static Arseny Solokha
2019-09-04 13:52 ` [PATCH 3/4] gianfar: cleanup gianfar.h Arseny Solokha
2019-09-04 13:52 ` [PATCH 4/4] gianfar: use DT more consistently when selecting PHY connection type Arseny Solokha
2019-09-05 10:28 ` [PATCH 0/4] gianfar: some assorted cleanup David Miller
2019-09-05 10:39 ` Vladimir Oltean
2019-09-04 13:54 ` [RFC PATCH 1/2] gianfar: convert to phylink Arseny Solokha
2019-09-04 13:53 ` Arseny Solokha
2019-07-23 15:17 ` [RFC PATCH 2/2] net: phylink: don't start and stop SGMII PHYs in SFP modules twice Arseny Solokha
2019-07-24 9:01 ` Russell King - ARM Linux admin [this message]
2019-07-24 13:31 ` [PATCH v2] " Arseny Solokha
2019-07-24 13:36 ` Andrew Lunn
2019-07-24 13:37 ` Russell King - ARM Linux admin
2019-07-24 21:38 ` 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=20190724090139.GG1330@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=andrew@lunn.ch \
--cc=asolokha@kb.kras.ru \
--cc=claudiu.manoil@nxp.com \
--cc=ioana.ciornei@nxp.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.