From: Florian Fainelli <f.fainelli@gmail.com>
To: Russell King - ARM Linux <linux@armlinux.org.uk>,
Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrew Lunn <andrew@lunn.ch>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Joao Pinto <joao.pinto@synopsys.com>
Subject: Re: [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks
Date: Mon, 22 Oct 2018 10:13:35 -0700 [thread overview]
Message-ID: <f8cd48a0-2cf5-5718-a6a6-1e9824834720@gmail.com> (raw)
In-Reply-To: <20181022154851.GA1492@n2100.armlinux.org.uk>
On 10/22/18 8:48 AM, Russell King - ARM Linux wrote:
> On Mon, Oct 22, 2018 at 01:47:48PM +0100, Jose Abreu wrote:
>> Hello,
>>
>> On 22-10-2018 13:28, Andrew Lunn wrote:
>>>> EXPORT_SYMBOL_GPL(gen10g_resume);
>>>> @@ -327,7 +381,7 @@ struct phy_driver genphy_10g_driver = {
>>>> .phy_id = 0xffffffff,
>>>> .phy_id_mask = 0xffffffff,
>>>> .name = "Generic 10G PHY",
>>>> - .soft_reset = gen10g_no_soft_reset,
>>>> + .soft_reset = gen10g_soft_reset,
>>>> .config_init = gen10g_config_init,
>>>> .features = 0,
>>>> .aneg_done = genphy_c45_aneg_done,
>>> Hi Jose
>>>
>>> You need to be careful here. There is a reason this is called
>>> gen10g_no_soft_reset, rather than having an empty
>>> gen10g_soft_reset. Some PHYs break when you do a reset. So adding a
>>> gen10g_soft_reset is fine, but don't change this here, without first
>>> understanding the history, and talking to Russell King.
>>
>> Hmm, the reset function only interacts with standard PCS
>> registers, which should always be available ...
>>
>> >From my tests I need to do at least 1 reset during power-up so in
>> ultimate case I can add a feature quirk or similar.
>>
>> Russell, can you please comment ?
>
> Setting the reset bit on 88x3310 causes the entire device to become
> completely inaccessible until hardware reset. Therefore, this bit
> must _never_ be set for these devices. That said, we have a separate
> driver for these PHYs, but that will only be used for them if it's
> present in the kernel. If we accidentally fall back to the generic
> driver, then we'll screw the 88x3310 until a full hardware reset.
>
> We also have a bunch of net devices that make use of this crippled
> "generic" 10G support - we don't know whether resetting the PHY
> for those systems will cause a regression - maybe board firmware
> already configured the PHY? I can't say either way on that, except
> that we've had crippled 10G support in PHYLIB for a number of years
> now _with_ users, and adding reset support drastically changes the
> subsystem's behaviour for these users.
>
> I would recommend not touching the generic 10G driver, but instead
> implement your own driver for your PHY to avoid causing regressions.
>
Agreed.
--
Florian
next prev parent reply other threads:[~2018-10-23 1:33 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-22 10:32 [PATCH net-next 0/4] net: phy: Misc improvements for Generic 10G PHY Jose Abreu
2018-10-22 10:32 ` [PATCH net-next 1/4] net: phy: Use C45 Helpers when forcing PHY Jose Abreu
2018-10-22 17:11 ` Florian Fainelli
2018-10-23 10:20 ` Jose Abreu
2018-10-22 10:32 ` [PATCH net-next 2/4] net: phy-c45: Populate autoneg_done callback Jose Abreu
2018-10-22 12:21 ` Andrew Lunn
2018-10-22 10:32 ` [PATCH net-next 3/4] net: phy-c45: Implement reset/suspend/resume callbacks Jose Abreu
2018-10-22 12:28 ` Andrew Lunn
2018-10-22 12:47 ` Jose Abreu
2018-10-22 15:48 ` Russell King - ARM Linux
2018-10-22 17:13 ` Florian Fainelli [this message]
2018-10-23 10:17 ` Jose Abreu
2018-10-23 10:20 ` Russell King - ARM Linux
2018-10-23 10:28 ` Jose Abreu
2018-10-23 10:58 ` Russell King - ARM Linux
2018-10-24 7:50 ` Jose Abreu
2018-10-24 12:03 ` Andrew Lunn
2018-10-23 12:38 ` Andrew Lunn
2018-10-22 10:32 ` [PATCH net-next 4/4] net: phy-c45: Populate missing features Jose Abreu
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=f8cd48a0-2cf5-5718-a6a6-1e9824834720@gmail.com \
--to=f.fainelli@gmail.com \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=joao.pinto@synopsys.com \
--cc=jose.abreu@synopsys.com \
--cc=linux@armlinux.org.uk \
--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 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).