lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Nov 2019 16:18:34 -0800 (PST) From: David Miller <davem@...emloft.net> To: linux@...linux.org.uk Cc: andrew@...n.ch, f.fainelli@...il.com, hkallweit1@...il.com, netdev@...r.kernel.org Subject: Re: [PATCH net-next 00/17] Allow slow to initialise GPON modules to work From: Russell King - ARM Linux admin <linux@...linux.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.
Powered by blists - more mailing lists