1. 26 6月, 2013 1 次提交
    • G
      net/tg3: Avoid delay during MMIO access · 6d446ec3
      Gavin Shan 提交于
      When the EEH error is the result of a fenced host bridge, MMIO accesses
      can be very slow (milliseconds) to timeout and return all 1's,
      thus causing the driver various timeout loops to take way too long and
      trigger soft-lockup warnings (in addition to taking minutes to recover).
      
      It might be worthwhile to check if for any of these cases, ffffffff is
      a valid possible value, and if not, bail early since that means the HW
      is either gone or isolated. In the meantime, checking that the PCI channel
      is offline would be workaround of the problem.
      
      Cc: <stable@vger.kernel.org> # v3.0+
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d446ec3
  2. 13 6月, 2013 1 次提交
    • N
      tg3: Wait for boot code to finish after power on · df465abf
      Nithin Sujir 提交于
      Some systems that don't need wake-on-lan may choose to power down the
      chip on system standby. Upon resume, the power on causes the boot code
      to startup and initialize the hardware. On one new platform, this is
      causing the device to go into a bad state due to a race between the
      driver and boot code, once every several hundred resumes. The same race
      exists on open since we come up from a power on.
      
      This patch adds a wait for boot code signature at the beginning of
      tg3_init_hw() which is common to both cases. If there has not been a
      power-off or the boot code has already completed, the signature will be
      present and poll_fw() returns immediately. Also return immediately if
      the device does not have firmware.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      df465abf
  3. 05 6月, 2013 1 次提交
  4. 23 5月, 2013 2 次提交
  5. 15 5月, 2013 2 次提交
  6. 01 5月, 2013 1 次提交
  7. 30 4月, 2013 1 次提交
  8. 20 4月, 2013 2 次提交
  9. 17 4月, 2013 1 次提交
  10. 10 4月, 2013 11 次提交
  11. 28 3月, 2013 1 次提交
  12. 18 3月, 2013 1 次提交
  13. 13 3月, 2013 1 次提交
  14. 09 3月, 2013 1 次提交
    • N
      tg3: Update link_up flag for phylib devices · 84421b99
      Nithin Sujir 提交于
      Commit f4a46d1f introduced a bug where
      the ifconfig stats would remain 0 for phylib devices. This is due to
      tp->link_up flag never becoming true causing tg3_periodic_fetch_stats()
      to return.
      
      The link_up flag was being updated in tg3_test_and_report_link_chg()
      after setting up the phy. This function however, is not called for
      phylib devices since the driver does not do the phy setup.
      
      This patch moves the link_up flag update into the common
      tg3_link_report() function that gets called for phylib devices as well
      for non phylib devices when the link state changes.
      
      To avoid updating link_up twice, we replace tg3_carrier_...() calls that
      are followed by tg3_link_report(), with netif_carrier_...(). We can then
      remove the unused tg3_carrier_on() function.
      
      CC: <stable@vger.kernel.org>
      Reported-by: NOGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
      Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      84421b99
  15. 08 3月, 2013 6 次提交
  16. 19 2月, 2013 2 次提交
  17. 16 2月, 2013 5 次提交