1. 11 8月, 2011 1 次提交
    • J
      cassini/niu/sun*: Move the Sun drivers · e689cf4a
      Jeff Kirsher 提交于
      Moves the Sun drivers into drivers/net/ethernet/sun/ and make
      the necessary Kconfig and Makefile changes.
      
      Oliver Hartkopp <socketcan@hartkopp.net> suggested removing the
      sun* prefix on the driver names.  This type of change I will
      leave up to the driver maintainers.
      
      CC: Sam Creasey <sammy@sammy.net>
      CC: Adrian Sun <asun@darksunrising.com>
      CC: Benjamin Herrenscmidt <benh@kernel.crashing.org>
      Signed-off-by: NJeff Kirsher <jeffrey.t.kirsher@intel.com>
      e689cf4a
  2. 19 8月, 2010 1 次提交
  3. 10 5月, 2010 1 次提交
  4. 04 4月, 2010 1 次提交
    • J
      net: convert multicast list to list_head · 22bedad3
      Jiri Pirko 提交于
      Converts the list and the core manipulating with it to be the same as uc_list.
      
      +uses two functions for adding/removing mc address (normal and "global"
       variant) instead of a function parameter.
      +removes dev_mcast.c completely.
      +exposes netdev_hw_addr_list_* macros along with __hw_addr_* functions for
       manipulation with lists on a sandbox (used in bonding and 80211 drivers)
      Signed-off-by: NJiri Pirko <jpirko@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      22bedad3
  5. 19 2月, 2010 1 次提交
  6. 30 12月, 2009 1 次提交
  7. 23 9月, 2009 1 次提交
    • J
      drivers/net: remove duplicate structure field initialization · 5ee21245
      Julia Lawall 提交于
      The definitions of vnet_ops and ehea_netdev_ops have initializations of a
      local function and eth_change_mtu for their respective ndo_change_mtu
      fields.  This change uses only the local function.
      
      The semantic match that finds this problem is as follows:
      (http://coccinelle.lip6.fr/)
      
      // <smpl>
      @r@
      identifier I, s, fld;
      position p0,p;
      expression E;
      @@
      
      struct I s =@p0 { ... .fld@p = E, ...};
      
      @s@
      identifier I, s, r.fld;
      position r.p0,p;
      expression E;
      @@
      
      struct I s =@p0 { ... .fld@p = E, ...};
      
      @script:python@
      p0 << r.p0;
      fld << r.fld;
      ps << s.p;
      pr << r.p;
      @@
      
      if int(ps[0].line)!=int(pr[0].line) or int(ps[0].column)!=int(pr[0].column):
        cocci.print_main(fld,p0)
      // </smpl>
      Signed-off-by: NJulia Lawall <julia@diku.dk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5ee21245
  8. 13 7月, 2009 2 次提交
  9. 20 3月, 2009 1 次提交
  10. 07 1月, 2009 1 次提交
  11. 28 10月, 2008 1 次提交
  12. 01 9月, 2008 1 次提交
  13. 03 2月, 2008 1 次提交
  14. 29 1月, 2008 1 次提交
  15. 01 8月, 2007 1 次提交
  16. 21 7月, 2007 1 次提交
  17. 20 7月, 2007 1 次提交
  18. 18 7月, 2007 2 次提交
  19. 16 7月, 2007 2 次提交
    • D
      [SPARC64]: Abstract out mdesc accesses for better MD update handling. · 43fdf274
      David S. Miller 提交于
      Since we have to be able to handle MD updates, having an in-tree
      set of data structures representing the MD objects actually makes
      things more painful.
      
      The MD itself is easy to parse, and we can implement the existing
      interfaces using direct parsing of the MD binary image.
      
      The MD is now reference counted, so accesses have to now take the
      form:
      
      	handle = mdesc_grab();
      
      	... operations on MD ...
      
      	mdesc_release(handle);
      
      The only remaining issue are cases where code holds on to references
      to MD property values.  mdesc_get_property() returns a direct pointer
      to the property value, most cases just pull in the information they
      need and discard the pointer, but there are few that use the pointer
      directly over a long lifetime.  Those will be fixed up in a subsequent
      changeset.
      
      A preliminary handler for MD update events from domain services is
      there, it is rudimentry but it works and handles all of the reference
      counting.  It does not check the generation number of the MDs,
      and it does not generate a "add/delete" list for notification to
      interesting parties about MD changes but that will be forthcoming.
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      43fdf274
    • D
      4c521e42