1. 22 9月, 2013 2 次提交
  2. 14 9月, 2013 1 次提交
  3. 13 9月, 2013 1 次提交
  4. 04 9月, 2013 1 次提交
  5. 30 8月, 2013 1 次提交
  6. 16 8月, 2013 1 次提交
  7. 10 8月, 2013 1 次提交
    • Y
      tg3: clean up unnecessary MSI/MSI-X capability find · 0f847584
      Yijing Wang 提交于
      PCI core will initialize device MSI/MSI-X capability in
      pci_msi_init_pci_dev(). So device driver should use
      pci_dev->msi_cap/msix_cap to determine whether the device
      support MSI/MSI-X instead of using
      pci_find_capability(pci_dev, PCI_CAP_ID_MSI/MSIX).
      Access to PCIe device config space again will consume more time.
      Signed-off-by: NYijing Wang <wangyijing@huawei.com>
      Cc: Nithin Nayak Sujir <nsujir@broadcom.com>
      Cc: Michael Chan <mchan@broadcom.com>
      Cc: netdev@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0f847584
  8. 30 7月, 2013 6 次提交
  9. 27 7月, 2013 2 次提交
    • G
      net/tg3: Fix warning from pci_disable_device() · c80dc13d
      Gavin Shan 提交于
      The patch fixes following warning. The PCI device might have been
      disabled somewhere else when we have EEH errors during early stage.
      
      Device tg3 disabling already-disabled device
      WARNING: at drivers/pci/pci.c:1403
      :
      NIP [c00000000044fd5c] .pci_disable_device+0xcc/0xe0
      LR [c00000000044fd58] .pci_disable_device+0xc8/0xe0
      Call Trace:
      [c000003f80bc7370] [c00000000044fd58] .pci_disable_device+0xc8/0xe0
      [c000003f80bc73f0] [d00000001cfe8fc0] .tg3_init_one+0x2f0/0x19f0 [tg3]
      [c000003f80bc74d0] [c0000000004534e8] .local_pci_probe+0x68/0xb0
      [c000003f80bc7560] [c0000000004537c8] .pci_device_probe+0x198/0x1a0
      [c000003f80bc7610] [c0000000004f9e98] .driver_probe_device+0xd8/0x450
      [c000003f80bc76a0] [c0000000004fa3bc] .__driver_attach+0x10c/0x110
      [c000003f80bc7730] [c0000000004f6e94] .bus_for_each_dev+0x94/0x100
      [c000003f80bc77d0] [c0000000004f9634] .driver_attach+0x34/0x50
      [c000003f80bc7850] [c0000000004f8f98] .bus_add_driver+0x288/0x380
      [c000003f80bc78f0] [c0000000004fae2c] .driver_register+0x9c/0x200
      [c000003f80bc7980] [c000000000453214] .__pci_register_driver+0x64/0x90
      [c000003f80bc7a10] [d00000001cff7a60] .tg3_driver_init+0x2c/0x40 [tg3]
      [c000003f80bc7a80] [c00000000000b424] .do_one_initcall+0x144/0x1f0
      [c000003f80bc7b70] [c0000000001244a0] .load_module+0x1f30/0x2700
      [c000003f80bc7d40] [c000000000124e80] .SyS_finit_module+0xc0/0x110
      [c000003f80bc7e30] [c000000000009dd4] syscall_exit+0x0/0x98
      Reported-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Acked-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      c80dc13d
    • G
      net/tg3: Fix kernel crash · d8af4dfd
      Gavin Shan 提交于
      While EEH error happens, we might not have network device instance
      (struct net_device) yet. So we can't access the instance safely and
      check its link state, which causes kernel crash. The patch fixes it.
      
      EEH: Frozen PE#2 on PHB#3 detected
      EEH: This PCI device has failed 1 times in the last hour
      EEH: Notify device drivers to shutdown
      (NULL net_device): PCI I/O error detected
      Unable to handle kernel paging request for data at address 0x00000048
      Faulting instruction address: 0xd00000001c9387a8
      Oops: Kernel access of bad area, sig: 11 [#1]
      SMP NR_CPUS=1024 NUMA PowerNV
      :
      NIP [d00000001c9387a8] .tg3_io_error_detected+0x78/0x2a0 [tg3]
      LR [d00000001c9387a4] .tg3_io_error_detected+0x74/0x2a0 [tg3]
      Call Trace:
      [c000003f93a0f960] [d00000001c9387a4] .tg3_io_error_detected+0x74/0x2a0 [tg3]
      [c000003f93a0fa30] [c00000000003844c] .eeh_report_error+0xac/0x120
      [c000003f93a0fac0] [c0000000000371bc] .eeh_pe_dev_traverse+0x8c/0x150
      [c000003f93a0fb60] [c000000000038858] .eeh_handle_normal_event+0x128/0x3d0
      [c000003f93a0fbf0] [c000000000038db8] .eeh_handle_event+0x2b8/0x2c0
      [c000003f93a0fc90] [c000000000038e80] .eeh_event_handler+0xc0/0x170
      [c000003f93a0fd30] [c0000000000cc000] .kthread+0xf0/0x100
      [c000003f93a0fe30] [c00000000000a0dc] .ret_from_kernel_thread+0x5c/0x80
      Reported-by: NWei Yang <weiyang@linux.vnet.ibm.com>
      Signed-off-by: NGavin Shan <shangw@linux.vnet.ibm.com>
      Acked-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8af4dfd
  10. 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
  11. 18 6月, 2013 1 次提交
    • M
      tg3: Prevent system hang during repeated EEH errors. · 72bb72b0
      Michael Chan 提交于
      The current tg3 code assumes the pci_error_handlers to be always called
      in sequence.  In particular, during ->error_detected(), NAPI is disabled
      and the device is shutdown.  The device is later reset and NAPI
      re-enabled in ->slot_reset() and ->resume().
      
      In EEH, if more than 6 errors are detected in a hour, only
      ->error_detected() will be called.  This will leave the driver in an
      inconsistent state as NAPI is disabled but netif_running state is still
      true.  When the device is later closed, we'll try to disable NAPI again
      and it will loop forever.
      
      We fix this by closing the device if we encounter any error conditions
      during the normal sequence of the pci_error_handlers.
      
      v2: Remove the changes in tg3_io_resume() based on Benjamin Poirier's
          feedback.
      Signed-off-by: NMichael Chan <mchan@broadcom.com>
      Signed-off-by: NNithin Nayak Sujir <nsujir@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      72bb72b0
  12. 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
  13. 05 6月, 2013 1 次提交
  14. 03 6月, 2013 1 次提交
  15. 25 5月, 2013 6 次提交
  16. 23 5月, 2013 3 次提交
  17. 20 5月, 2013 4 次提交
  18. 15 5月, 2013 2 次提交
  19. 01 5月, 2013 1 次提交
  20. 30 4月, 2013 1 次提交
  21. 20 4月, 2013 2 次提交