From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Jakub Kicinski <kuba@kernel.org>
Cc: "Bjørn Mork" <bjorn@mork.no>,
netdev@vger.kernel.org, 照山周一郎 <teruyama@springboard-inc.jp>
Subject: Re: [PATCH net,stable] phy: sfp: fix high power modules without diag mode
Date: Fri, 3 Dec 2021 12:58:03 +0000 [thread overview]
Message-ID: <YaoUW9KHyEQOt46b@shell.armlinux.org.uk> (raw)
In-Reply-To: <YaoFkZ53m7cILdYu@shell.armlinux.org.uk>
On Fri, Dec 03, 2021 at 11:54:57AM +0000, Russell King (Oracle) wrote:
> On Thu, Dec 02, 2021 at 05:58:43PM -0800, Jakub Kicinski wrote:
> > On Tue, 30 Nov 2021 08:39:29 +0100 Bjørn Mork wrote:
> > > Commit 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change
> > > modules") changed semantics for high power modules without diag mode.
> > > We repeatedly try to read the current power status from the non-existing
> > > 0xa2 address, in the futile hope this failure is temporary:
> > >
> > > [ 8.856051] sfp sfp-eth3: module NTT 0000000000000000 rev 0000 sn 0000000000000000 dc 160408
> > > [ 8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode
> > > [ 8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
> > > [ 8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
> > > [ 9.103250] sfp sfp-eth3: Failed to read EEPROM: -5
> > >
> > > Eeprom dump:
> > >
> > > 0x0000: 03 04 01 00 00 00 80 00 00 00 00 01 0d 00 0a 64
> > > 0x0010: 00 00 00 00 4e 54 54 20 20 20 20 20 20 20 20 20
> > > 0x0020: 20 20 20 20 00 00 00 00 30 30 30 30 30 30 30 30
> > > 0x0030: 30 30 30 30 30 30 30 30 30 30 30 30 05 1e 00 7d
> > > 0x0040: 02 00 00 00 30 30 30 30 30 30 30 30 30 30 30 30
> > > 0x0050: 30 30 30 30 31 36 30 34 30 38 20 20 00 00 00 75
> > > 0x0060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x0070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x0080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x0090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > > 0x00f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > >
> > > Previously we assumed such modules were powered up in the correct
> > > mode, continuing without further configuration as long as the
> > > required power class was supported by the host.
> > >
> > > Revert to that behaviour, refactoring to keep the improved
> > > diagnostic messages.
> > >
> > > Fixes: 7cfa9c92d0a3 ("net: sfp: avoid power switch on address-change modules")
> > > Reported-and-tested-by: 照山周一郎 <teruyama@springboard-inc.jp>
> > > Cc: Russell King <rmk+kernel@armlinux.org.uk>
> > > Signed-off-by: Bjørn Mork <bjorn@mork.no>
> >
> > Russell, any comments?
>
> Sorry for the delay, I've been out over the last couple of days. I
> hink it's fine, but the code here is not easy to understand, hence
> why this subtlety was missed. So, I'm not entirely happy about going
> back to the original code.
>
> Maybe instead doing a check in sfp_sm_mod_hpower() for this would
> be better? Possibly something like:
>
> static int sfp_module_parse_power(struct sfp *sfp)
> {
> u32 power_mW = 1000;
> + bool supports_a2;
>
> if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_POWER_DECL))
> power_mW = 1500;
> if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_HIGH_POWER_LEVEL))
> power_mW = 2000;
>
> + supports_a2 = sfp->id.ext.sff8472_compliance !=
> + SFP_SFF8472_COMPLIANCE_NONE ||
> + sfp->id.ext.diagmon & SFP_DIAGMON_DDM;
>
> if (power_mW > sfp->max_power_mW) {
> /* Module power specification exceeds the allowed maximum. */
> - if (sfp->id.ext.sff8472_compliance ==
> - SFP_SFF8472_COMPLIANCE_NONE &&
> - !(sfp->id.ext.diagmon & SFP_DIAGMON_DDM)) {
> + if (!supports_a2) {
> ...
> }
> +
> + if (!supports_a2 && power_mW > 1000) {
> + /* The module power level is below the host maximum and the
> + * module appears not to implement bus address 0xa2, so assume
> + * that the module powers up in the indicated mode.
> + */
> + return 0;
> + }
>
> /* If the module requires a higher power mode, but also requires
> ...
>
> This way, if the module reports it doesn't support 0xa2, we don't get
> the "Address Change Sequence not supported" message - since if 0xa2 is
> not supported, then the address change sequence is irrelevant. However,
> modules shouldn't have that bit set... but "shouldn't" doesn't mean
> they do not.
>
> This also has the advantage of making the check explicit and obvious,
> and I much prefer the organisation of:
>
> if (module_exceeds_host_power) {
> handle this case
> } else {
> do other checks
> }
>
> I think maybe dealing with power_mW <= 1000 early on may be a good idea,
> and eliminates the tests further down for power_mW > 1000.
>
> if (power_mW <= 1000) {
> sfp->module_power_mW = power_mW;
> return 0;
> }
>
> since those modules do not require any special handling.
Thinking a little more, how about this:
drivers/net/phy/sfp.c | 25 +++++++++++++++++++++----
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 51a1da50c608..4c900d063b19 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -1752,17 +1752,20 @@ static int sfp_sm_probe_for_phy(struct sfp *sfp)
static int sfp_module_parse_power(struct sfp *sfp)
{
u32 power_mW = 1000;
+ bool supports_a2;
if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_POWER_DECL))
power_mW = 1500;
if (sfp->id.ext.options & cpu_to_be16(SFP_OPTIONS_HIGH_POWER_LEVEL))
power_mW = 2000;
+ supports_a2 = sfp->id.ext.sff8472_compliance !=
+ SFP_SFF8472_COMPLIANCE_NONE ||
+ sfp->id.ext.diagmon & SFP_DIAGMON_DDM;
+
if (power_mW > sfp->max_power_mW) {
/* Module power specification exceeds the allowed maximum. */
- if (sfp->id.ext.sff8472_compliance ==
- SFP_SFF8472_COMPLIANCE_NONE &&
- !(sfp->id.ext.diagmon & SFP_DIAGMON_DDM)) {
+ if (!supports_a2) {
/* The module appears not to implement bus address
* 0xa2, so assume that the module powers up in the
* indicated mode.
@@ -1779,11 +1782,24 @@ static int sfp_module_parse_power(struct sfp *sfp)
}
}
+ if (power_mW <= 1000) {
+ /* Modules below 1W do not require a power change sequence */
+ return 0;
+ }
+
+ if (!supports_a2) {
+ /* The module power level is below the host maximum and the
+ * module appears not to implement bus address 0xa2, so assume
+ * that the module powers up in the indicated mode.
+ */
+ return 0;
+ }
+
/* If the module requires a higher power mode, but also requires
* an address change sequence, warn the user that the module may
* not be functional.
*/
- if (sfp->id.ext.diagmon & SFP_DIAGMON_ADDRMODE && power_mW > 1000) {
+ if (sfp->id.ext.diagmon & SFP_DIAGMON_ADDRMODE) {
dev_warn(sfp->dev,
"Address Change Sequence not supported but module requires %u.%uW, module may not be functional\n",
power_mW / 1000, (power_mW / 100) % 10);
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2021-12-03 12:58 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-30 7:39 [PATCH net,stable] phy: sfp: fix high power modules without diag mode Bjørn Mork
2021-12-03 1:58 ` Jakub Kicinski
2021-12-03 11:54 ` Russell King (Oracle)
2021-12-03 12:58 ` Russell King (Oracle) [this message]
2021-12-03 13:55 ` Bjørn Mork
2021-12-04 12:38 ` Russell King (Oracle)
2021-12-06 10:35 ` Bjørn Mork
2021-12-06 15:39 ` 照山周一郎
2021-12-30 11:43 ` Bjørn Mork
2021-12-30 11:55 ` Russell King (Oracle)
2021-12-30 12:00 ` 照山周一郎
2022-01-15 16:58 ` Christian Lamparter
2022-01-17 14:24 ` Russell King (Oracle)
2022-01-17 14:44 ` Bjørn Mork
2022-01-17 14:49 ` Christian Lamparter
2022-01-18 6:58 ` 照山周一郎
2021-12-03 13:41 ` Bjørn Mork
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=YaoUW9KHyEQOt46b@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=bjorn@mork.no \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=teruyama@springboard-inc.jp \
/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.