From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
Heiner Kallweit <hkallweit1@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
netdev@vger.kernel.org
Subject: Re: [PATCH net-next 00/17] Allow slow to initialise GPON modules to work
Date: Sun, 10 Nov 2019 18:52:17 +0100 [thread overview]
Message-ID: <20191110175217.GL25889@lunn.ch> (raw)
In-Reply-To: <20191110140530.GA25745@shell.armlinux.org.uk>
On Sun, Nov 10, 2019 at 02:05:30PM +0000, Russell King - ARM Linux admin wrote:
> Some GPON modules take longer than the SFF MSA specified time to
> initialise and respond to transactions on the I2C bus for either
> both 0x50 and 0x51, or 0x51 bus addresses. Technically these modules
> are non-compliant with the SFP Multi-Source Agreement, they have
> been around for some time, so are difficult to just ignore.
Hi Russell
We are seeing quite a few SFP/SFF which violate the spec. Do you think
there is any value in naming and shaming in the kernel logs SFP which
don't conform to the standard? If you need to wait longer than 1
second for the EEPROM to become readable, print the vendor name from
the EEPROM and warn it is not conforment. If the diagnostic page is
not immediately available, again, print the vendor name warn it is not
conforment?
Andrew
next prev parent reply other threads:[~2019-11-10 17:52 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-10 14:05 [PATCH net-next 00/17] Allow slow to initialise GPON modules to work Russell King - ARM Linux admin
2019-11-10 14:06 ` [PATCH net-next 01/17] net: sfp: move sfp sub-state machines into separate functions Russell King
2019-11-10 17:56 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 02/17] net: sfp: move tx disable on device down to main state machine Russell King
2019-11-10 18:00 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 03/17] net: sfp: rename sfp_sm_ins_next() as sfp_sm_mod_next() Russell King
2019-11-10 18:01 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 04/17] net: sfp: handle module remove outside state machine Russell King
2019-11-10 18:07 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 05/17] net: sfp: rename T_PROBE_WAIT to T_SERIAL Russell King
2019-11-10 18:08 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 06/17] net: sfp: parse SFP power requirement earlier Russell King
2019-11-10 18:10 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 07/17] net: sfp: avoid power switch on address-change modules Russell King
2019-11-10 18:12 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 08/17] net: sfp: control TX_DISABLE and phy only from main state machine Russell King
2019-11-10 18:14 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 09/17] net: sfp: split the PHY probe from sfp_sm_mod_init() Russell King
2019-11-10 18:19 ` Andrew Lunn
2019-11-10 14:06 ` [PATCH net-next 10/17] net: sfp: eliminate mdelay() from PHY probe Russell King
2019-11-10 19:37 ` Andrew Lunn
2019-11-10 19:59 ` Russell King - ARM Linux admin
2019-11-10 14:07 ` [PATCH net-next 11/17] net: sfp: allow fault processing to transition to other states Russell King
2019-11-10 14:07 ` [PATCH net-next 12/17] net: sfp: ensure TX_FAULT has deasserted before probing the PHY Russell King
2019-11-10 14:07 ` [PATCH net-next 13/17] net: sfp: track upstream's attachment state in state machine Russell King
2019-11-10 14:07 ` [PATCH net-next 14/17] net: sfp: split power mode switching from probe Russell King
2019-11-10 14:07 ` [PATCH net-next 15/17] net: sfp: move module insert reporting out of probe Russell King
2019-11-10 14:07 ` [PATCH net-next 16/17] net: sfp: allow sfp to probe slow to initialise GPON modules Russell King
2019-11-10 14:07 ` [PATCH net-next 17/17] net: sfp: allow modules with slow diagnostics to probe Russell King
2019-11-10 17:52 ` Andrew Lunn [this message]
2019-11-10 19:47 ` [PATCH net-next 00/17] Allow slow to initialise GPON modules to work Russell King - ARM Linux admin
2019-11-12 0:18 ` 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=20191110175217.GL25889@lunn.ch \
--to=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=hkallweit1@gmail.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).