Re: [PATCH net-next 00/17] Allow slow to initialise GPON modules to work

[David Miller <davem@davemloft.net>]

From: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Date: Sun, 10 Nov 2019 14:05:30 +0000

> 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.

Series applied.