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.

 drivers/net/phy/sfp.c | 526 +++++++++++++++++++++++++++++++++++---------------
 1 file changed, 369 insertions(+), 157 deletions(-)

RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up