1. 02 11月, 2011 6 次提交
    • C
      net/ethernet: sc92031 is not Realtek · 1b6b7172
      Cesar Eduardo Barros 提交于
      While the SC92031 could be found on fake "Realtek" NICs, it has no
      relationship to Realtek, and is actually from Silan.
      
      Create a new subdirectory for silan and move sc92031 there.
      Signed-off-by: NCesar Eduardo Barros <cesarb@cesarb.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1b6b7172
    • P
      isdn: hisax: Fix typo 'HISAX_DE_AOC' · 048ca169
      Paul Bolle 提交于
      That should probably be 'CONFIG_DE_AOC'.
      Signed-off-by: NPaul Bolle <pebolle@tiscali.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      048ca169
    • A
      net: make the tcp and udp file_operations for the /proc stuff const · 73cb88ec
      Arjan van de Ven 提交于
      the tcp and udp code creates a set of struct file_operations at runtime
      while it can also be done at compile time, with the added benefit of then
      having these file operations be const.
      
      the trickiest part was to get the "THIS_MODULE" reference right; the naive
      method of declaring a struct in the place of registration would not work
      for this reason.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      73cb88ec
    • W
      bonding:update speed/duplex for NETDEV_CHANGE · 98f41f69
      Weiping Pan 提交于
      Zheng Liang(lzheng@redhat.com) found a bug that if we config bonding with
      arp monitor, sometimes bonding driver cannot get the speed and duplex from
      its slaves, it will assume them to be 100Mb/sec and Full, please see
      /proc/net/bonding/bond0.
      But there is no such problem when uses miimon.
      
      (Take igb for example)
      I find that the reason is that after dev_open() in bond_enslave(),
      bond_update_speed_duplex() will call igb_get_settings()
      , but in that function,
      it runs ethtool_cmd_speed_set(ecmd, -1); ecmd->duplex = -1;
      because igb get an error value of status.
      So even dev_open() is called, but the device is not really ready to get its
      settings.
      
      Maybe it is safe for us to call igb_get_settings() only after
      this message shows up, that is "igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex,
      Flow Control: RX".
      
      So I prefer to update the speed and duplex for a slave when reseices
      NETDEV_CHANGE/NETDEV_UP event.
      
      Changelog
      V2:
      1 remove the "fake 100/Full" logic in bond_update_speed_duplex(),
        set speed and duplex to -1 when it gets error value of speed and duplex.
      2 delete the warning in bond_enslave() if bond_update_speed_duplex() returns
        error.
      3 make bond_info_show_slave() handle bad values of speed and duplex.
      Signed-off-by: NWeiping Pan <wpan@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      98f41f69
    • M
      vlan: Don't propagate flag changes on down interfaces. · deede2fa
      Matthijs Kooijman 提交于
      When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
      flags are cleared or set on the underlying interface. So, if these flags
      are changed on a vlan interface that is not up, the flags underlying
      interface might be set or cleared twice.
      
      Only propagating flag changes when a device is up makes sure this does
      not happen. It also makes sure that an underlying device is not set to
      promiscuous or allmulti mode for a vlan device that is down.
      Signed-off-by: NMatthijs Kooijman <matthijs@stdin.nl>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      deede2fa
    • D
      neigh: Kill bogus SMP protected debugging message. · 045f7b3b
      David S. Miller 提交于
      Whatever situations make this state legitimate when SMP
      also would be legitimate when !SMP and f.e. preemption is
      enabled.
      
      This is dubious enough that we should just delete it entirely.  If we
      want to add debugging for neigh timer races, better more thorough
      mechanisms are needed.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      045f7b3b
  2. 01 11月, 2011 34 次提交