aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/net/ethernet/realtek
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2019-11-11 16:17:01 -0800
committerDavid S. Miller <davem@davemloft.net>2019-11-11 16:17:01 -0800
commit7a28c886f645e5c7c3b26981e29dc70c803f6ae9 (patch)
tree475456142a2b707b7bb7cb86e2740114e0e9e0ca /drivers/net/ethernet/realtek
parentnet: sfp: fix sfp_bus_put() kernel documentation (diff)
parentnet: sfp: allow modules with slow diagnostics to probe (diff)
downloadlinux-dev-7a28c886f645e5c7c3b26981e29dc70c803f6ae9.tar.xz
linux-dev-7a28c886f645e5c7c3b26981e29dc70c803f6ae9.zip
Merge branch 'sfp-Allow-slow-to-initialise-GPON-modules-to-work'
Russell King says: ==================== sfp: Allow slow to initialise GPON modules to work 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. Most of the patch series is restructuring the code to make it more readable, and split various things into separate functions. We split the three state machines into three separate functions, and re-arrange them to start probing the module as soon as a module has been detected (without waiting for the network device.) We try to read the module's EEPROM, retrying quickly for the first second, and then once every five seconds for about a minute until we have read the EEPROM. So that the kernel isn't entirely silent, we print a message indicating that we're waiting for the module to respond after the first second, or when all retries have expired. Once the module ID has been read, we kick off a delayed work queue which attempts to register the hwmon, retrying for up to a minute if the monitoring parameters are unreadable; this allows us to proceed with module initialisation independently of the hwmon state. With high-power modules, we wait for the netdev to be attached before switching the module power mode, and retry this in a similar way to before until we have successfully read and written the EEPROM at 0x51. We also move the handling of the TX_DISABLE signal entirely to the main state machine, and avoid probing any on-board PHY while TX_FAULT is set. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/ethernet/realtek')
0 files changed, 0 insertions, 0 deletions