netdev - Re: tn40xx / qt2025: cannot load firmware, error -2

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: <621e6614-d2a8-4f7a-be53-9f24b1768040@lunn.ch>
Date: Wed, 5 Mar 2025 18:57:09 +0100
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: max.schulze@...ine.de, hfdevel@....net, netdev@...r.kernel.org
Subject: Re: tn40xx / qt2025: cannot load firmware, error -2

> > From my reading of the PHY datasheet, it can do 1000Base-KX, but there
> > is no mention of 100BaseSX. There is also limited access to the i2c
> > eeprom in the SFP, so ethtool -m could be implemented.
> 
> Yeah, I have not yet found a way to implement the ethtool operation
> that accesses the SFP and returns the appropriate information.

There are two different ways you can report the i2c EEPROM
information:

struct phy_driver has:

        /**
         * @module_info: Get the size and type of the eeprom contained
         * within a plug-in module
         */
        int (*module_info)(struct phy_device *dev,
                           struct ethtool_modinfo *modinfo);

        /**
         * @module_eeprom: Get the eeprom information from the plug-in
         * module
         */
        int (*module_eeprom)(struct phy_device *dev,
                             struct ethtool_eeprom *ee, u8 *data);

I don't think any PHY driver actually implement these. I've been
intending to remove them for a couple of years, but have been too
lazy. I would actually say this is a dead end and you should not do
this.

What i think you should do is fake an I2C bus. This is how all other
boards work, they have a Linux i2c bus device, and phylink knows how
to use it to retrieve the EEPROM contents and export it in the
standard way. You are going to need phylink involved anyway to manage
the SFP cage, determine the link modes, tell the MAC driver what to
do. The PHY driver then needs a sfp_upstream_ops which it registers
with phy_sfp_probe(). See marvell10g.c for an example.

	Andrew