1. 27 1月, 2018 3 次提交
  2. 26 1月, 2018 30 次提交
  3. 25 1月, 2018 7 次提交
    • I
      net/ibm/emac: wrong bit is used for STA control register write · 624ca9c3
      Ivan Mikhaylov 提交于
      STA control register has areas of mode and opcodes for opeations. 18 bit is
      using for mode selection, where 0 is old MIO/MDIO access method and 1 is
      indirect access mode. 19-20 bits are using for setting up read/write
      operation(STA opcodes). In current state 'read' is set into old MIO/MDIO mode
      with 19 bit and write operation is set into 18 bit which is mode selection,
      not a write operation. To correlate write with read we set it into 20 bit.
      All those bit operations are MSB 0 based.
      Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      624ca9c3
    • I
      net/ibm/emac: add 8192 rx/tx fifo size · 45d6e545
      Ivan Mikhaylov 提交于
      emac4syn chips has availability to use 8192 rx/tx fifo buffer sizes,
      in current state if we set it up in dts 8192 as example, we will get
      only 2048 which may impact on network speed.
      Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      45d6e545
    • N
      fm10k: clarify action when updating the VLAN table · e0752a68
      Ngai-Mint Kwan 提交于
      Clarify the comment for when entering promiscuous mode that we update
      the VLAN table. Add a comment distinguishing the case where we're
      exiting promiscuous mode and need to clear the entire VLAN table.
      Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@gmail.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e0752a68
    • N
    • J
      fm10k: don't assume VLAN 1 is enabled · 74d2950c
      Jacob Keller 提交于
      Since commit 856dfd69e84f ("fm10k: Fix multicast mode synch issues",
      2016-03-03) we've incorrectly assumed that VLAN 1 is enabled when the
      default VID is not set.
      
      This occurs because we check the default_vid and if it's zero, start
      several loops over the active_vlans bitmask at 1, instead of checking to
      ensure that that bit is active.
      
      This happened because of commit d9ff3ee8efe9 ("fm10k: Add support for
      VLAN 0 w/o default VLAN", 2014-08-07) which mistakenly assumed that we
      should send requests for MAC and VLAN filters with VLAN 0 when the
      default_vid isn't set.
      
      However, the switch generally considers this an invalid configuration,
      so the only time we'd have a default_vid of 0 is when the switch is
      down.
      
      Instead, lets just not request any filters for the default_vid if it's
      not yet been assigned.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      74d2950c
    • J
      fm10k: stop adding VLAN 0 to the VLAN table · 8c2c5039
      Jacob Keller 提交于
      Currently, when the driver loads, it sends a request to add VLAN 0 to the
      VLAN table. For the PF, this is honored, and VLAN 0 is indeed set. For
      the VF, this request is silently converted into a request for the
      default VLAN as defined by either the switch vid or the PF vid.
      
      This results in the odd behavior that the VLAN table doesn't appear
      consistent between the PF and the VF.
      
      Furthermore, setting a MAC filter with VLAN 0 is generally considered an
      invalid configuration by the switch, and since commit 856dfd69e84f
      ("fm10k: Fix multicast mode synch issues", 2016-03-03) we've had code
      which prevents us from ever sending such a request.
      
      Since there's not really a good reason to keep VLAN 0 in the VLAN table,
      stop requesting it in fm10k_restore_rx_state().
      
      This might seem to indicate that we would no longer properly configure
      the MAC and VLAN tables for the default vid. However, due to the way
      that fm10k_find_next_vlan() behaves, it will always return the
      default_vid as enabled.
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      8c2c5039
    • N
      fm10k: fix "failed to kill vid" message for VF · cf315ea5
      Ngai-Mint Kwan 提交于
      When a VF is under PF VLAN assignment:
      
      ip link set <pf> vf <#> vlan <vid>
      
      This will remove all previous entries in the VLAN table including those
      generated by VLAN interfaces created on the VF. The issue arises when
      the VF is under PF VLAN assignment and one or more of these VLAN
      interfaces of the VF are deleted. When deleting these VLAN interfaces,
      the following message will be generated in "dmesg":
      
      failed to kill vid 0081/<vid> for device <vf>
      
      This is due to the fact that "ndo_vlan_rx_kill_vid" exits with an error.
      The handler for this ndo is "fm10k_update_vid". Any calls to this
      function while under PF VLAN management will exit prematurely and, thus,
      it will generate the failure message.
      
      Additionally, since "fm10k_update_vid" exits prematurely, none of the
      VLAN update is performed. So, even though the actual VLAN interfaces of
      the VF will be deleted, the active_vlans bitmask is not cleared. When
      the VF is no longer under PF VLAN assignment, the driver mistakenly
      restores the previous entries of the VLAN table based on an
      unsynchronized list of active VLANs.
      
      The solution to this issue involves checking the VLAN update action type
      before exiting "fm10k_update_vid". If the VLAN update action type is to
      "add", this action will not be permitted while the VF is under PF VLAN
      assignment and the VLAN update is abandoned like before.
      
      However, if the VLAN update action type is to "kill", then we need to
      also clear the active_vlans bitmask. However, we don't need to actually
      queue any messages to the PF, because the MAC and VLAN tables have
      already been cleared, and the PF would silently ignore these requests
      anyways.
      Signed-off-by: NNgai-Mint Kwan <ngai-mint.kwan@intel.com>
      Signed-off-by: NJacob Keller <jacob.e.keller@intel.com>
      Tested-by: NKrishneil Singh <krishneil.k.singh@intel.com>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      cf315ea5