---------- Forwarded message ----------
From: "Eugene T. Bordenkircher" <[email protected]>
Date: Oct 22, 8:39?am
Subject: Problem with MDI/MDI-X auto-switching in E100 driver
To: fa.linux.kernel
Around line 1466 of e100.c (git master) is the following code to turn
on
MDI/MDI-X auto-switching if it is not already.
? ? ? ? ?} else if ((nic->mac >= mac_82550_D102) || ((nic->flags &
ich) &&
? ? ? ? ? ? ?(mdio_read(netdev, nic->mii.phy_id, MII_TPISTATUS) &
0x8000) &&
? ? ? ? ? ? ? ? ? !(nic->eeprom[eeprom_cnfg_mdix] &
eeprom_mdix_enabled))) {
? ? ? ? ? ? ? ? ? /* enable/disable MDI/MDI-X auto-switching. */
? ? ? ? ? ? ? ? ? mdio_write(netdev, nic->mii.phy_id, MII_NCONFIG,
? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? nic->mii.force_media ? 0 :
NCONFIG_AUTO_SWITCH);
? ? ? ? ?}
This code is broken in the case where an 8255x is used without
magnetics. ?Per
Intel Application note 435, without the magnetics, auto switching is
not
possible. ?The only way to turn this off without driver modifications
is to set
the force_media flag via ethtool, which has the side effect of turning
off all
auto-negotiation. This happens to be the case on a product I am
currently
working on.
It seems a better solution to this is to trust the eeprom's
configuration
rather than override it. ?Am I missing something or does this sound
reasonable?
Eugene T. Bordenkircher
Hi,
bad devel, bad! Ought to have CC'd some other guys and me ;)
(just happened to stumble on it by accident)
> It seems a better solution to this is to trust the eeprom's configuration
> rather than override it. Am I missing something or does this sound
> reasonable?
I don't have much actual experience with various e100 versions,
so I cannot confirm it, but if something like this gets implemented,
then it's perhaps best to restrict the possibly more dangerous
"trust eeprom" reverted logic to your chip version only.
Or is the "without magnetics" feature independent of particular chip
versions? Then of course that wouldn't help ;)
...and yet another edge case which e100 doesn't support as well as it
should. (would eepro100 have worked here?)
Anyway, one should just attempt to get it working nicely with e100,
no use complaining. :)
Andreas Mohr
> bad devel, bad! Ought to have CC'd some other guys and me ;)
> (just happened to stumble on it by accident)
I'm not sure what you mean by 'other guys' but let's try a few people out of
the MAINTAINERS, file as well as yourself, rather than the contact information
in the header of the file :)
>> It seems a better solution to this is to trust the eeprom's configuration
>> rather than override it. Am I missing something or does this sound
>> reasonable?
>
> I don't have much actual experience with various e100 versions,
> so I cannot confirm it, but if something like this gets implemented,
> then it's perhaps best to restrict the possibly more dangerous
> "trust eeprom" reverted logic to your chip version only.
> Or is the "without magnetics" feature independent of particular chip
> versions? Then of course that wouldn't help ;)
I'm a software guy, but I've had our hardware guys try to explain it to me.
Forgive me if this doesn't make any sense to someone who knows hardware. As I
understand it, the 'magnetics' is how it gets hooked up post Phy, so
theoretically the magnetic-less implementation can occur for almost any chip
and is not isolated to just ours (82551IT, which I didn't mention before). So I
believe it's a wider problem. According to the afore mentioned App Note. Auto
-switching is not possible when the phy is connected 'without the magnetics' so
this feature should be turned off. We turned it off in the configuration
eeprom, but the e100 driver is turning it back on.
We've also discovered that with the feature on in a device that does have the
magnetics, it's causing problems with certain switches that also implement
auto-switching, most notably Netgear's FS108. They both attempt to auto switch
and for some reason they end up getting into a state where one is in MDI mode
and the other is in MDI-X. In that case, it would be nice to be able to force
it off.
The 'force on' that the driver does seems unnecessary since the feature is
configurable via the eeprom, but I'm not versed on all chip variants the e100
driver supports which is why I'm here looking for a bit of knowledge and help.