From: Antoine Tenart <antoine.tenart@bootlin.com>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: Antoine Tenart <antoine.tenart@bootlin.com>,
Andrew Lunn <andrew@lunn.ch>,
davem@davemloft.net, linux@armlinux.org.uk, hkallweit1@gmail.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
thomas.petazzoni@bootlin.com, maxime.chevallier@bootlin.com,
gregory.clement@bootlin.com, miquel.raynal@bootlin.com,
nadavh@marvell.com, stefanc@marvell.com, mw@semihalf.com
Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default
Date: Mon, 4 Mar 2019 11:47:00 +0100 [thread overview]
Message-ID: <20190304104700.GB3709@kwain> (raw)
In-Reply-To: <d17bdf0c-f1b8-99e3-b199-a99a7f7347d3@gmail.com>
Hi Florian,
On Fri, Mar 01, 2019 at 07:08:56PM -0800, Florian Fainelli wrote:
> On 3/1/2019 7:07 AM, Antoine Tenart wrote:
> > On Fri, Mar 01, 2019 at 03:19:53PM +0100, Andrew Lunn wrote:
> >> On Fri, Mar 01, 2019 at 12:00:47PM +0100, Antoine Tenart wrote:
> >>> When the Marvell 10G PHYs are set out of reset, the LPOWER bit is set
> >>> depending on an hardware configuration choice. We also do not know what
> >>> is the PHY state at boot time. Hence, set the PHY in low power by
> >>> default when this driver probes.
> >>
> >> Florian did some work for c22 PHYs so that the existing link state
> >> could be used at boot. So for example, the bootloader configured the
> >> PHY up and it got link, there is no need to down/up the PHY when linux
> >> takes control. The networking comes up faster that way.
> >>
> >> Can this work for this PHY?
> >
> > This use case (the bootloader configures the PHY, Linux boots and sets
> > an interface using this PHY up) would work, and is what's happening in
> > some situations right now (the 3310 reset is never asserted prior to
> > this series).
> >
> > But consider this case (let's say we use a 10G link):
> >
> > ---------------- ----------------
> > | Board 1 | | Board 2 |
> > | MAC — 3310 — | — SFP cable — | — 3310 — MAC |
> > ---------------- ----------------
> >
> > Board 1: The userspace do not set the interface up. The MAC is in reset
> > (default state during the MAC driver probe), the PHY was
> > configured by the bootloader.
> > Board 2: The userspace set the interface up. The MAC is configured, the
> > PHY is configured as well.
> >
> > The two PHY's PCS will establish a link and report it as being up. In
> > this case, phylink's AN mode is MLO_AN_PHY and thus will report the
> > overall link as being the PHY's link status: up.
> >
> > My understanding is that the issue arises because the PHYs were never
> > set in reset, or low power, and thus act as if the user wanted the port
> > to be up. As the default behaviour for networking ports is to be down at
> > boot, I thought to set the PHY as well in a default low power state.
>
> The policy you are creating here for the marvell10g driver is entirely
> applicable to any PHY <=> PHY configuration where either of the two
> software agents on Board 1 or Board 2 has not had a chance to bring-up
> its bootloader/OS/applications to control the PHY.
Right.
> A number of PHYs come up fully on (or in isolate or super isolate mode)
> and will AN with their link partner if connected. For some people it's a
> feature, for some it is a waste of power. I don't necessarily have an
> issue with your patch per-se, but it does create an one off behavior
> that other PHY drivers may not follow.
I agree having a per-driver behaviour is not something we want. As I
understand it, there is no behaviour enforced currently regarding this
matter. I agree both cases have their pros and cons:
- It's weird to have an interface reporting being UP when it's not
really.
- Having the link come up faster can be a feature.
I have some questions then:
- Do you think calling suspend() in the core when probing a PHY driver
would work for all PHYs?
- Would a new Kconfig option selecting the default behaviour at boot
time be a solution?
- Or this is a WONTFIX kind of (small) issues? :)
Thanks!
Antoine
--
Antoine Ténart, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
next prev parent reply other threads:[~2019-03-04 10:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-01 11:00 [PATCH net-next v2 0/3] net: phy: marvell10g: implement suspend/resume callbacks Antoine Tenart
2019-03-01 11:00 ` [PATCH net-next v2 1/3] " Antoine Tenart
2019-03-01 14:16 ` Andrew Lunn
2019-03-01 11:00 ` [PATCH net-next v2 2/3] net: phy: marvell10g: add the suspend/resume callbacks for the 88x2210 Antoine Tenart
2019-03-01 14:15 ` Andrew Lunn
2019-03-01 11:00 ` [PATCH net-next v2 3/3] net: phy: marvell10g: set the PHY in low power by default Antoine Tenart
2019-03-01 14:19 ` Andrew Lunn
2019-03-01 15:07 ` Antoine Tenart
2019-03-02 3:08 ` Florian Fainelli
2019-03-04 10:47 ` Antoine Tenart [this message]
2019-03-04 16:10 ` Russell King - ARM Linux admin
2019-03-05 12:54 ` Antoine Tenart
2019-03-04 18:46 ` [PATCH net-next v2 0/3] net: phy: marvell10g: implement suspend/resume callbacks 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=20190304104700.GB3709@kwain \
--to=antoine.tenart@bootlin.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=gregory.clement@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=miquel.raynal@bootlin.com \
--cc=mw@semihalf.com \
--cc=nadavh@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=stefanc@marvell.com \
--cc=thomas.petazzoni@bootlin.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).