netdev - Re: SFP: Copper module with different PHY address (Netgear AGM734)

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]

Date:   Fri, 28 Apr 2023 22:15:55 +0200
From:   Andreas Böhler <news@...ehler.at>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: SFP: Copper module with different PHY address (Netgear AGM734)

Hi,
thanks for the quick reply!

On 26/04/2023 19:04, Andrew Lunn wrote:
> On Wed, Apr 26, 2023 at 06:47:33PM +0200, Andreas Böhler wrote:
>> Hi,
>>
>> I have a bunch of Netgear AGM734 copper SFP modules that I would like to use
>> with my switches. Upon insertion, a message "no PHY detected" pops up.
>>
>> Upon further investigation I found out that the Marvell PHY in these modules
>> is at 0x53 and not at the expected 0x56. A quick check with a changed
>> SFP_PHY_ADDR works as expected.
>>
>> Which is the best scenario to proceed?
>>
>> 1. Always probe SFP_PHY_ADDR and SFP_PHY_ADDR - 3
>>
>> 2. Create a fixup for this specific module to probe at a different address.
>> However, I'm afraid this might break "compatible" modules.
>>
>> 3. Something else?
> 
> 
> What does ethtool -m show?

Offset          Values
------          ------
0x0000:         03 04 00 00 00 00 08 00 00 00 00 01 0d 00 00 00
0x0010:         00 00 64 00 4e 45 54 47 45 41 52 20 20 20 20 20
0x0020:         20 20 20 20 00 00 09 5b 41 47 4d 37 33 34 20 20
0x0030:         20 20 20 20 20 20 20 20 30 30 30 30 00 00 00 7e
0x0040:         00 01 00 00 31 38 31 36 30 34 31 30 30 33 34 37
0x0050:         20 20 20 20 31 38 30 34 32 35 30 31 00 00 00 79
0x0060:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0070:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0080:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0090:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00a0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00b0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00c0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00d0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00e0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x00f0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This is the output of i2cdetect -y 0:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: 50 -- -- 53 -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --


> Is there something we a key a quirk off?

Unfortunately, I don't understand this sentence.

> Is it a true Netgear SFP?

Yes, it's a brand new original Netgear module.

> There are OEMs which will load there EEPROM to emulate other
> vendors. e.g.:

Yes, this is what I meant with a quirk might break "compatible" modules.

Regards,
Andreas