Message-ID: <eeeabc11-89ec-449a-95f8-679872d694fe@lunn.ch>
Date: Thu, 25 Apr 2024 16:37:54 +0200
From: Andrew Lunn <andrew@...n.ch>
To: FUJITA Tomonori <fujita.tomonori@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH net-next v1 5/5] net: tn40xx: add PHYLIB support

> I updated the code to use phylink and posted v2. At least seems that
> it works with 10G SFP+ as before.
> 
> I suppose that more changes are necessary for full support. For
> example, with 1G SFP inserted, the MAC driver has to configure the
> hardware for 1G. I'll investigate once I get 1G SFP.
> 
> Note that the original driver supports only 10G SFP+.

This is where the Rust PHY driver gets more interesting.

A PHY which is being used as a media converter needs to support a few
additional things. The marvel10g driver is a good example to follow
for some things. Look at mv3310_sfp_ops.

But there is more to it than that. phylink assumes it has access to
the i2c bus the module is on. The datasheet for the QT2025, shows a
couple of diagrams how an SFP is connected to it. The QT2025 has an
I2C bus which should be connected to the SFP cage. So you need to
export this I2C bus master in the PHY driver. So a Rust I2C bus
driver. Has anybody done that yet? However, it is not clear from my
reading of the datasheet if you get true access to the I2C bus. It
says:

XFP/SFP+ Module Access through MDIO

The MDIO interface can be used to access an XFP or
SFP+ module. The XFP/SFP+ module 2-wire interface
must be connected to the UC_SCL and UC_SDA clock
and data lines. The XFP module address is 1010000,
while the SFP+ module uses memory at addresses
1010000 and 1010001. The entire module address
space will be automatically read upon powerup, reset
or module hotplug by detection of the MOD_ABS
signal. A 400ms delay is observed before upload to
allow the module to initialize.
The memory at module address 1010000 is mapped to
MDIO register range 3.D000 - 3.D0FFh. Read/write
access to the module memory is controlled by MDIO
register 3.D100h. This applies to both module types.

The memory at module address 1010001 is mapped to
MDIO register range 1.8007 - 1.8106h. No read/write
access to the module memory is provided.

DOM Memory Access
The SFP+ DOM memory (A2) is mapped to MDIO
registers 1.8007-1.8106h (the NVR address space) or
alternatively to 1.A000-1.A0FF (this is firmware load
dependent; it may be configurable). If mapped to
1.A000-1.A0FF, DOM-related alarms in the SFP+
module will feed into the LASI alarm tree (see “Link
Alarm Status Interrupt Pin (LASI)” on page 74 for
details).

Later firmware versions implement a DOM periodic
polling feature, where the DOM memory is read at
every 1s. Optical alarms will then automatically alert
the host system through the LASI interrupt pins. Only a
subset of registers containing dynamically changing
values are polled on each update. Consult AMCC for
details on this feature.

So i guess you are going to need to fake the I2C bus, mapping I2C
transfer requests into MDIO reads of the mapped memory.

Additionally, phylink expects a few GPIO for Los of Signal, TX Enable,
TX Fault, etc. The PHY has these, so the PHY driver needs to export a
GPIO driver.

And then you need some glue, to bring all the parts together. The
wangxun Ethernet driver has mostly solved this, so you can take
inspiration from there.

You picked an interesting device to add Rust support for.

	Andrew

Powered by blists - more mailing lists