1. 16 8月, 2016 2 次提交
  2. 15 8月, 2016 4 次提交
    • W
      net: macb: add missing free_netdev() on error in macb_probe() · b22ae0b4
      Wei Yongjun 提交于
      Add the missing free_netdev() before return from function macb_probe()
      in the platform_get_irq() error handling case.
      
      Fixes: c69618b3 ("net/macb: fix probe sequence to setup clocks earlier")
      Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b22ae0b4
    • W
      qed: Fix possible memory leak in qed_dcbnl_get_ieee_pfc() · 02ee9b18
      Wei Yongjun 提交于
      'dcbx_info is malloced in qed_dcbnl_get_ieee_pfc() and should be freed
      before leaving from the error handling cases, otherwise it will cause
      memory leak.
      
      Fixes: a1d8d8a5 ("qed: Add dcbnl support.")
      Signed-off-by: NWei Yongjun <weiyj.lk@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      02ee9b18
    • H
      cxgb4/cxgb4vf: Add set VF mac address support · 858aa65c
      Hariprasad Shenai 提交于
      Add ndo_set_vf_mac support which allows to set the MAC address
      for cxgb4vf interfaces from the host
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      858aa65c
    • H
      cxgb4: Add control net_device for configuring PCIe VF · 7829451c
      Hariprasad Shenai 提交于
      Issue:
      For instance, the current APIs assume a 1-to-1 mapping of Network Ports,
      Physical Functions and the SR-IOV Virtual Functions of those Physical
      Functions. This is not the case with our cards where any Virtual
      Function can be hooked up to any Port -- or any number of Ports the
      current Linux APIs also assume only 1 Network Interface/Port can be
      accessed per Virtual Function.
      
      Another issue is that these APIs assume that the Administrative Driver
      is attached to the Physical Function Associated with a Virtual Function.
      This is not the case with our card where all administration is performed
      by a Driver which is not attached to any of the Physical Functions which
      have SR-IOV PCI Capabilities.
      
      Another consequence of these assumptions is the inability to utilize all
      of the cards SR-IOV resources. For instance, our cards have SR-IOV
      Capabilities on Physical Functions 0..3 and the administrative Driver
      attaches to Physical Function 4. Each of the Physical Functions 0..3 can
      support up to 16 Virtual Functions. With the current Linux APIs, a
      2-Port card would only be able to use the Virtual Functions on Physical
      Function 0..1 and not allow the Virtual Functions on Physical Functions
      2..3 to be used since there are no Ports 2..3 on a 2-Port card.
      
      Fix:
      Since the control node is always the netdevice for all VF ACL commands.
      Created a dummy netdevice for each Physical Function from 0 to 3 through
      which one could control their VFs. The device won't be associated with
      any port, since it doesn't need to transmit/receive. Its purely used
      for VF management purpose only. The device will be registered only when
      VF for a particular PF is configured using PCI sysfs interface and
      unregistered while pci_disable_sriov() for the PF is called.
      Signed-off-by: NHariprasad Shenai <hariprasad@chelsio.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7829451c
  3. 14 8月, 2016 32 次提交
  4. 13 8月, 2016 2 次提交