1. 19 12月, 2013 5 次提交
    • M
      drivers: net cpsw: Enable In Band mode in cpsw for 10 mbps · a81d8762
      Mugunthan V N 提交于
      This patch adds support for enabling In Band mode in 10 mbps speed.
      RGMII supports 1 Gig and 100 mbps mode for Forced mode of operation.
      For 10mbps mode it should be configured to in band mode so that link
      status, duplexity and speed are determined from the RGMII input data
      stream
      Signed-off-by: NMugunthan V N <mugunthanvnm@ti.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a81d8762
    • D
      Merge branch 'bond_locking' · 405a96d6
      David S. Miller 提交于
      Ding Tianhong says:
      
      ====================
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed and
      bond_3ad_adapter_duplex_changed is called with RTNL only, and
      the functions will modify the port's information with no further
      locking, they will not mutex against bond state machine and
      incoming LACPDU which do not hold RTNL, So I add port lock to
      protect the port information.
      
      But they are not critical bugs, they exist since day one, and till
      now they have never been hit and reported, because change for speed
      and duplex is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup the comments together.
      ====================
      Signed-off-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      405a96d6
    • D
      bonding: protect port for bond_3ad_handle_link_change() · 108db736
      dingtianhong 提交于
      The bond_3ad_handle_link_change is called with RTNL only,
      and the function will modify the port's information with
      no further locking, it will not mutex against bond state
      machine and incoming LACPDU which do not hold RTNL, So I
      add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it and
      add a new pr_debug to debug the port message.
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      108db736
    • D
      bonding: protect port for bond_3ad_adapter_duplex_changed() · bca44a73
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_duplex_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comments in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bca44a73
    • D
      bonding: protect port for bond_3ad_adapter_speed_changed() · 71a06c59
      dingtianhong 提交于
      Jay Vosburgh said that the bond_3ad_adapter_speed_changed is
      called with RTNL only, and the function will modify the port's
      information with no further locking, it will not mutex against
      bond state machine and incoming LACPDU which do not hold RTNL,
      So I add __get_state_machine_lock to protect the port.
      
      But it is not a critical bug, it exist since day one, and till
      now it has never been hit and reported, because changes to
      speed is very rare, and will not occur critical problem.
      
      The comment in the function is very old, cleanup it.
      Suggested-by: NJay Vosburgh <fubar@us.ibm.com>
      Signed-off-by: NDing Tianhong <dingtianhong@huawei.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      71a06c59
  2. 18 12月, 2013 28 次提交
  3. 17 12月, 2013 6 次提交
  4. 16 12月, 2013 1 次提交