[ipxe-devel] [Mohon Peak] Add support for internal SGMII controller

[Michael Brown]

On 25/05/15 08:04, Patrick Agrain wrote:
> Parsing the intel.c - intel.h code, I have the feeling IMHO that this
> code is not able to manage external PHYs, which, actually is not a
> problem, because the managed controllers also have an internal PHY.
>
> Let me know if I'm wrong...
>
> The chip that I tried to include in the IPXE source tree (8086-1F41) is
> based on the Intel i354.
>  From an Intel point of view, this chip can be managed with the Intel
> igb driver.
> The difference with all controllers managed in the IPXE intel.c driver
> is that the 8086-1F41 _requires_ an external PHY, because it is embedded
> in the Rangeley Atom processor.
>
> Therefore I'm facing a problem. What to do ?
> - Either trying to merge the external PHY control from Intel igb driver
> to the IPXE source tree ?
> - Or merge the Intel igb driver into the IPXE source tree (what I
> already proposed) ? But in that case, most of the controllers in the
> intel.c driver would be duplicated in the Intel igb driver.
> - Or ... ?
>
> What do you think ? Any hint would be welcome.

Does the external PHY support MII?  There is already some functionality 
in iPXE to support basic control of a PHY via MII: see drivers/net/mii.c.

The Intel driver does not currently include support for MII, but this 
could viably be added (and may help to solve a problem that Robin 
Smidsrød <robin at smidsrod.no> has been observing in which some Intel NICs 
seem to reset to 10Mbps link speed).  You can see in 
drivers/net/realtek.c an example of how a PHY interface is created (via 
mii_init()) and used (via mii_reset() in realtek_phy_reset()).

Most of the code in the Intel igb driver will be irrelevant, since iPXE 
doesn't support (and doesn't want to support) anything more 
sophisticated than the basic "reset PHY and autonegotiate link" mode of 
operation.

I would be very happy to see MII support added to the Intel driver, and 
potentially to see the generic iPXE MII support improved.  (For example: 
the manipulation of the CTRL1000 register done in realtek_phy_speed() 
should probably be part of mii.c instead.)

Michael