Problem with MDI/MDI-X auto-switching in E100 driver

Problem with MDI/MDI-X auto-switching in E100 driver

[Eugene T. Bordenkircher]

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

Problem with MDI/MDI-X auto-switching in E100 driver

[Eugene Bordenkircher]

---------- Forwarded message ----------
From: "Eugene T. Bordenkircher" <eug...@gmail.com>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-
kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Problem with MDI/MDI-X auto-switching in E100 driver

[Andreas Mohr]

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

Re: Problem with MDI/MDI-X auto-switching in E100 driver

[Eugene T. Bordenkircher]

> 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.