RE: Problem in phy.c, when using fixed network speed

Hi all,
during testing i encountered a problem with setting
up a 5200B controller with a MICREL phy at static
100MBit full duplex - without autonegotiation.

I performed this as usual with ethtool and was
succesful when i had my link partner up, providing
a link.

When kepping the link partner off, meaning no link
at all, my machine started to degrade its link
capabilities ending 10MBit half duplex.

I tracked it down to drivers/net/phy/phy.c:
in the function phy_state_machine, the case block
PHY_FORCING causes this (at least for me) undesired
behaviour. Calling the phy_force_reduction function
degrades actually an intentionally static setup.

I deactivated those lines, and it works for me.

But anyhow i feel soe need to have a general
solution that takes static non autonagotiation
setups into account.

What do you think?

Hope to hear from you

Michael

Yes, I have encountered this before. I think it dates=20
back to before Auto Negotiation became part of the=20
IEEE802* standard and each manufacturer implemented=20
its own strategy to establish a link. Although it is=20
possible "by experiment" to find the speed of your=20
link partner, it is impossible to determine its=20
Full/Half Duplex mode. IMHO when a fixed speed and=20
duplex setting is applied, phy.c should keep that=20
setting regardless of whether or not the link is=20
established. Not only is this undesirable behaviour,=20
but it deviates from the standard.

Clive