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

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20191111.161834.1399688973316931565.davem@davemloft.net>
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.