1. 22 2月, 2018 6 次提交
  2. 21 2月, 2018 1 次提交
  3. 15 2月, 2018 5 次提交
  4. 10 2月, 2018 2 次提交
  5. 09 2月, 2018 1 次提交
  6. 08 2月, 2018 2 次提交
  7. 06 2月, 2018 1 次提交
  8. 02 2月, 2018 1 次提交
  9. 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
  10. 23 1月, 2018 3 次提交
  11. 19 1月, 2018 2 次提交
  12. 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
  13. 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
  14. 09 1月, 2018 1 次提交
  15. 20 12月, 2017 2 次提交
  16. 18 11月, 2017 1 次提交
  17. 14 11月, 2017 1 次提交
  18. 11 11月, 2017 1 次提交
  19. 27 10月, 2017 2 次提交
  20. 19 10月, 2017 3 次提交
  21. 18 10月, 2017 1 次提交
  22. 01 10月, 2017 1 次提交