netdev - Re: [PATCH net-next 2/2] net: sfp: enhance quirk for Fibrestore 2.5G copper SFP module

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <919416c4-334a-42da-8140-3ee85e71c15a@gmail.com>
Date: Tue, 23 Apr 2024 10:51:09 +0200
From: Eric Woudstra <ericwouds@...il.com>
To: Marek Behún <kabel@...nel.org>
Cc: netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>,
 Raju Lakkaraju <Raju.Lakkaraju@...rochip.com>,
 Frank Wunderlich <frank-w@...lic-files.de>,
 Simon Horman <simon.horman@...igine.com>, Andrew Lunn <andrew@...n.ch>,
 Heiner Kallweit <hkallweit1@...il.com>
Subject: Re: [PATCH net-next 2/2] net: sfp: enhance quirk for Fibrestore 2.5G
 copper SFP module



On 4/23/24 10:40, Marek Behún wrote:

>>
>> Also any code I found for the yt8821 is C22 only. And even more, even
>> though we are facing with an almost similar MCU, RollBall protocol does
>> not work. I think it is almost the same mcu, as it responds to the same
>> eeprom password, and also the rollball password does something, but not
>> give the expected result.
>>
> 
> What about I2C address 0x56?
> 
> I noticed that the Fibrestore FS SFP-2.5G-T with the realtek chip
> also exposes clause 22 registers, but the current mdio-i2c driver wont
> work, because the module implements the access in an incompatible way
> (we would need to extend mdio-i2c).
> 
> Eric, can you check whether the motorcomm module exposes something on
> address 0x56? With i2cdump, i.e. on omnia:
>   i2cdump -y 5 0x56
> (you will need to change 5 to the i2c controller of the sfp cage).
> What does it print?
> 
> Marek

The device at 0x56 is not up at the time the eeprom is checked and read.
So when it is time to decide whether to use RollBall protocol or not,
the data at 0x56 cannot be used.

We have more info on i2cdumps on the BPI forum (rtl8221b topic and
yt8821 topic).