1. 11 Nov, 2009 12 commits
  2. 10 Nov, 2009 22 commits
  3. 08 Nov, 2009 6 commits
    • Christian Pellegrin's avatar
    • Eric W. Biederman's avatar
      net: Support specifying the network namespace upon device creation. · 81adee47
      Eric W. Biederman authored
      
      
      There is no good reason to not support userspace specifying the
      network namespace during device creation, and it makes it easier
      to create a network device and pass it to a child network namespace
      with a well known name.
      
      We have to be careful to ensure that the target network namespace
      for the new device exists through the life of the call.  To keep
      that logic clear I have factored out the network namespace grabbing
      logic into rtnl_link_get_net.
      
      In addtion we need to continue to pass the source network namespace
      to the rtnl_link_ops.newlink method so that we can find the base
      device source network namespace.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@aristanetworks.com>
      Acked-by: default avatarEric Dumazet <eric.dumazet@gmail.com>
      81adee47
    • Sebastian Siewior's avatar
      net/fsl_pq_mdio: add module license GPL · 26062897
      Sebastian Siewior authored
      
      
      or it will taint the kernel and fail to load becuase
      of_address_to_resource() is GPL only.
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      26062897
    • Wolfgang Grandegger's avatar
      can: fix WARN_ON dump in net/core/rtnetlink.c:rtmsg_ifinfo() · 53a0ef86
      Wolfgang Grandegger authored
      
      
      On older kernels, e.g. 2.6.27, a WARN_ON dump in rtmsg_ifinfo()
      is thrown when the CAN device is registered due to insufficient
      skb space, as reported by various users. This patch adds the
      rtnl_link_ops "get_size" to fix the problem. I think this patch
      is required for more recent kernels as well, even if no WARN_ON
      dumps are triggered. Maybe we also need "get_xstats_size" for
      the CAN xstats.
      Signed-off-by: default avatarWolfgang Grandegger <wg@grandegger.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      53a0ef86
    • Anton Vorontsov's avatar
      gianfar: Fix compiler and sparse warnings · 18294ad1
      Anton Vorontsov authored
      commit fba4ed03
      
       ("gianfar: Add Multiple
      Queue Support") introduced the following warnings:
      
        CHECK   gianfar.c
      gianfar.c:333:8: warning: incorrect type in assignment (different address spaces)
      gianfar.c:333:8:    expected unsigned int [usertype] *baddr
      gianfar.c:333:8:    got unsigned int [noderef] <asn:2>*<noident>
      [... 67 lines skipped ...]
      gianfar.c:2565:3: warning: incorrect type in argument 1 (different type sizes)
      gianfar.c:2565:3:    expected unsigned long const *addr
      gianfar.c:2565:3:    got unsigned int *<noident>
        CC      gianfar.o
      gianfar.c: In function 'gfar_probe':
      gianfar.c:985: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:985: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:993: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:993: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c: In function 'gfar_configure_coalescing':
      gianfar.c:1680: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:1680: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:1688: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:1688: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c: In function 'gfar_poll':
      gianfar.c:2565: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:2565: warning: passing argument 1 of 'find_next_bit' from incompatible pointer type
      gianfar.c:2566: warning: passing argument 2 of 'test_bit' from incompatible pointer type
      gianfar.c:2585: warning: passing argument 2 of 'set_bit' from incompatible pointer type
      
      Following warnings left unfixed (looks like sparse doesn't like
      locks in loops, so __acquires/__releases() doesn't help):
      
      gianfar.c:441:40: warning: context imbalance in 'lock_rx_qs': wrong count at exit
      gianfar.c:441:40:    context '<noident>': wanted 0, got 1
      gianfar.c:449:40: warning: context imbalance in 'lock_tx_qs': wrong count at exit
      gianfar.c:449:40:    context '<noident>': wanted 0, got 1
      gianfar.c:458:3: warning: context imbalance in 'unlock_rx_qs': __context__ statement expected different context
      gianfar.c:458:3:    context '<noident>': wanted >= 0, got -1
      gianfar.c:466:3: warning: context imbalance in 'unlock_tx_qs': __context__ statement expected different context
      gianfar.c:466:3:    context '<noident>': wanted >= 0, got -1
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      18294ad1
    • Anton Vorontsov's avatar
      fsl_pq_mdio: Fix compiler/sparse warnings (part 2) · 6748f60b
      Anton Vorontsov authored
      
      
      This patch fixes following warnings:
      
      fsl_pq_mdio.c:112:38: warning: cast adds address space to expression (<asn:2>)
      fsl_pq_mdio.c:124:38: warning: cast adds address space to expression (<asn:2>)
      fsl_pq_mdio.c:133:38: warning: cast adds address space to expression (<asn:2>)
      fsl_pq_mdio.c:414:11: warning: cast adds address space to expression (<asn:2>)
      
      Instead of adding __force all over the place, introduce convenient
      fsl_pq_mdio_get_regs() call that does the ugly casting just once.
      Signed-off-by: default avatarAnton Vorontsov <avorontsov@ru.mvista.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6748f60b