linux-toradex.git/drivers/net/e1000e, branch tegra Linux kernel for Apalis and Colibri modules e1000e: workaround invalid Tx/Rx tail descriptor register write 2011-08-13T09:15:38+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-29T05:53:02+00:00 c6e7f51e73c1bc6044bce989ec503ef2e4758d55 When the Manageability Engine (ME) is enabled on 82579, it periodically accesses some MAC CSR registers. There is an arbiter in hardware which prevents simultaneous access of these registers by the host software, i.e. the driver. There is a hardware bug in the aribter that signals a host access of the registers later than it actually happens. A write of the Transmit or Receive Descriptor Tail register could result in an incorrect value if the driver and ME perform simultaneous accesses which could result in an access to an invalid memory address. This would return an Unsupported Request which could hang the hardware. Workaround the issue by checking the FWSM register bit24 which is set by ME before it accesses the MAC CSR registers. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
When the Manageability Engine (ME) is enabled on 82579, it periodically
accesses some MAC CSR registers.  There is an arbiter in hardware which
prevents simultaneous access of these registers by the host software, i.e.
the driver.  There is a hardware bug in the aribter that signals a host
access of the registers later than it actually happens.  A write of the
Transmit or Receive Descriptor Tail register could result in an incorrect
value if the driver and ME perform simultaneous accesses which could result
in an access to an invalid memory address.  This would return an
Unsupported Request which could hang the hardware.  Workaround the issue by
checking the FWSM register bit24 which is set by ME before it accesses the
MAC CSR registers.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: workaround for packet drop on 82579 at 100Mbps 2011-08-13T09:12:31+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-29T05:52:56+00:00 0ed013e28fe853244f4972cf18d8e2bd62eeb8fc The MAC can drop short packets when the PHY detects noise on the line at 100Mbps due to a timing issue. Workaround the issue by increasing the PLL counter so the PHY properly recognizes the synchronization pattern from the MAC. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
The MAC can drop short packets when the PHY detects noise on the line at
100Mbps due to a timing issue.  Workaround the issue by increasing the PLL
counter so the PHY properly recognizes the synchronization pattern from the
MAC.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: Spurious interrupts & dropped packets with 82577/8/9 in half-duplex 2011-08-13T09:11:48+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-22T06:21:56+00:00 1d2101a712b3b7281a19ff6d7bfc16c2ce9d3998 On 82577/8/9 in half-duplex when a received packet is passed from the PHY to the MAC, if too many preamble octects are stripped from the packet before arriving at the MAC, it can be misintrepeted as an in-band message rather than an actual frame. For example, if the frame contents resembled an interrupt request in-band message, it would trigger a false interrupt. In most cases, the packet is just dropped. By reducing the number of preamble octets stripped from the beginning of the frame when passing it from the PHY to the MAC, the MAC will interpret the frame properly. An additional uses of the magic PHY_REG(770, 16) have been updated with a define introduced with this patch. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
On 82577/8/9 in half-duplex when a received packet is passed from the PHY
to the MAC, if too many preamble octects are stripped from the packet
before arriving at the MAC, it can be misintrepeted as an in-band message
rather than an actual frame.  For example, if the frame contents resembled
an interrupt request in-band message, it would trigger a false interrupt.
In most cases, the packet is just dropped.

By reducing the number of preamble octets stripped from the beginning of
the frame when passing it from the PHY to the MAC, the MAC will interpret
the frame properly.

An additional uses of the magic PHY_REG(770, 16) have been updated with a
define introduced with this patch.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: increase driver version number 2011-08-11T22:23:58+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-22T06:22:02+00:00 12440928dca77eccc8a793cf3cd83d017abbd7d6 Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: alternate MAC address update 2011-08-11T22:21:05+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-29T05:53:07+00:00 244735f6ebccbf72a283db89472309f770e14c80 If word 0x37 in the EEPROM is 0xFFFF _or_ 0x0000, then there is no alternate MAC address in the EEPROM. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
If word 0x37 in the EEPROM is 0xFFFF _or_ 0x0000, then there is no
alternate MAC address in the EEPROM.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: do not disable receiver on 82574/82583 2011-08-11T22:19:06+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-22T06:21:35+00:00 7f99ae633884043c70f4cc4a03f43dad0f0ecba2 Due to a hardware erratum, the receiver on 82574 and 82583 should not be stopped once it has been started. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
Due to a hardware erratum, the receiver on 82574 and 82583 should not be
stopped once it has been started.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: alternate MAC address does not work on device id 0x1060 2011-08-11T22:16:28+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-22T06:21:51+00:00 c407bee8a56d874b91f3e4ee790660959ff1a25e This issue is present all the way back to 2.6.34 kernels. CC: <stable@kernel.org> Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Jeffrey Pieper <jeffrey.e.pieper@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
This issue is present all the way back to 2.6.34 kernels.

CC: <stable@kernel.org>
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by: Jeffrey Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: minor re-order of #include files 2011-08-04T12:01:24+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-29T05:52:51+00:00 9fb7a5f77b26dedfcfa4e3a36fe207f818662bee The recent commit a6b7a407 when back-ported to the out-of-tree e1000e driver caused a compilation error on older kernels which required a re-ordering of the #include files. This cosmetic patch syncs the two drivers for easier maintainability. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
The recent commit a6b7a407 when back-ported to the out-of-tree e1000e
driver caused a compilation error on older kernels which required a
re-ordering of the #include files.  This cosmetic patch syncs the two
drivers for easier maintainability.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by:  Aaron Brown  <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
e1000e: remove unnecessary check for NULL pointer 2011-08-04T12:00:21+00:00 Bruce Allan bruce.w.allan@intel.com 2011-07-22T06:21:41+00:00 b9e06f70dc186f8353cc593f2b4609383b3be7a9 The array shadow_ram is never NULL. Signed-off-by: Bruce Allan <bruce.w.allan@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
The array shadow_ram is never NULL.

Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Tested-by:  Aaron Brown  <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
intel drivers: repair missing flush operations 2011-08-04T11:59:07+00:00 Jesse Brandeburg jesse.brandeburg@intel.com 2011-07-20T00:56:21+00:00 945a51517cc0bd9e461f2018624dfc1faef9ddee after review of all intel drivers, found several instances where drivers had the incorrect pattern of: memory mapped write(); delay(); which should always be: memory mapped write(); write flush(); /* aka memory mapped read */ delay(); explanation: The reason for including the flush is that writes can be held (posted) in PCI/PCIe bridges, but the read always has to complete synchronously and therefore has to flush all pending writes to a device. If a write is held and followed by a delay, the delay means nothing because the write may not have reached hardware (maybe even not until the next read) Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> 
after review of all intel drivers, found several instances where
drivers had the incorrect pattern of:
memory mapped write();
delay();

which should always be:
memory mapped write();
write flush(); /* aka memory mapped read */
delay();

explanation:
The reason for including the flush is that writes can be held
(posted) in PCI/PCIe bridges, but the read always has to complete
synchronously and therefore has to flush all pending writes to a
device.  If a write is held and followed by a delay, the delay
means nothing because the write may not have reached hardware
(maybe even not until the next read)

Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by:  Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>