1. 10 2月, 2018 2 次提交
  2. 09 2月, 2018 1 次提交
  3. 08 2月, 2018 2 次提交
  4. 06 2月, 2018 1 次提交
  5. 02 2月, 2018 1 次提交
  6. 30 1月, 2018 1 次提交
    • T
      ibmvnic: Wait for device response when changing MAC · f813614f
      Thomas Falcon 提交于
      Wait for a response from the VNIC server before exiting after setting
      the MAC address. The resolves an issue with bonding a VNIC client in
      ALB or TLB modes. The bonding driver was changing the MAC address more
      rapidly than the device could respond, causing the following errors.
      
      "bond0: the hw address of slave eth2 is in use by the bond;
      couldn't find a slave with a free hw address to give it
      (this should not have happened)"
      
      If the function waits until the change is finalized, these errors are
      avoided.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f813614f
  7. 23 1月, 2018 3 次提交
  8. 19 1月, 2018 2 次提交
  9. 17 1月, 2018 1 次提交
    • T
      ibmvnic: Fix pending MAC address changes · 3d166130
      Thomas Falcon 提交于
      Due to architecture limitations, the IBM VNIC client driver is unable
      to perform MAC address changes unless the device has "logged in" to
      its backing device. Currently, pending MAC changes are handled before
      login, resulting in an error and failure to change the MAC address.
      Moving that chunk to the end of the ibmvnic_login function, when we are
      sure that it was successful, fixes that.
      
      The MAC address can be changed when the device is up or down, so
      only check if the device is in a "PROBED" state before setting the
      MAC address.
      
      Fixes: c26eba03 ("ibmvnic: Update reset infrastructure to support tunable parameters")
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Reviewed-by: NJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3d166130
  10. 12 1月, 2018 1 次提交
    • N
      ibmvnic: Don't handle RX interrupts when not up. · 09fb35ea
      Nathan Fontenot 提交于
      Initiating a kdump via the command line can cause a pending interrupt
      to be handled by the ibmvnic driver when initializing the sub-CRQ
      irqs during driver initialization.
      
      NIP [d000000000ca34f0] ibmvnic_interrupt_rx+0x40/0xd0 [ibmvnic]
      LR [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
      Call Trace:
      [c000000047fcfde0] [c000000008132ef0] __handle_irq_event_percpu+0xa0/0x2f0
      [c000000047fcfea0] [c00000000813317c] handle_irq_event_percpu+0x3c/0x90
      [c000000047fcfee0] [c00000000813323c] handle_irq_event+0x6c/0xd0
      [c000000047fcff10] [c0000000081385e0] handle_fasteoi_irq+0xf0/0x250
      [c000000047fcff40] [c0000000081320a0] generic_handle_irq+0x50/0x80
      [c000000047fcff60] [c000000008014984] __do_irq+0x84/0x1d0
      [c000000047fcff90] [c000000008027564] call_do_irq+0x14/0x24
      [c00000003c92af00] [c000000008014b70] do_IRQ+0xa0/0x120
      [c00000003c92af50] [c000000008002594] hardware_interrupt_common+0x114/0x180
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      09fb35ea
  11. 09 1月, 2018 1 次提交
  12. 20 12月, 2017 2 次提交
  13. 18 11月, 2017 1 次提交
  14. 14 11月, 2017 1 次提交
  15. 11 11月, 2017 1 次提交
  16. 27 10月, 2017 2 次提交
  17. 19 10月, 2017 3 次提交
  18. 18 10月, 2017 1 次提交
  19. 01 10月, 2017 1 次提交
  20. 18 8月, 2017 1 次提交
  21. 10 8月, 2017 3 次提交
  22. 08 8月, 2017 1 次提交
  23. 04 8月, 2017 4 次提交
  24. 03 8月, 2017 1 次提交
  25. 25 7月, 2017 1 次提交
    • J
      ibmvnic: Check for transport event on driver resume · a248878d
      John Allen 提交于
      On resume, the ibmvnic driver will fail to resume normal operation.
      The main crq gets closed on suspend by the vnic server and doesn't get
      reopened again as the interrupt for the transport event that would reset
      the main crq comes in after the driver has been suspended.
      
      This patch resolves the issue by removing the calls to kick the receive
      interrupts handlers and instead directly invoking the main crq interrupt
      handler. This will ensure that we see the transport event necessary to
      properly resume the driver.
      Signed-off-by: NJohn Allen <jallen@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a248878d
  26. 30 6月, 2017 1 次提交
    • T
      ibmvnic: Fix assignment of RX/TX IRQ's · 5df969c3
      Thomas Falcon 提交于
      The driver currently creates RX/TX queues during device probe, but
      assigns IRQ's to them during device open. On reset, however,
      IRQ's are assigned when resetting the queues. If there is a reset
      while the device is closed and the device is later opened, the driver will
      request IRQ's twice, causing the open to fail. This patch assigns
      the IRQ's in the ibmvnic_init function after the queues are reset or
      initialized, ensuring IRQ's are only requested once.
      Signed-off-by: NThomas Falcon <tlfalcon@linux.vnet.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5df969c3