1. 14 7月, 2016 2 次提交
  2. 13 7月, 2016 10 次提交
  3. 12 7月, 2016 23 次提交
  4. 11 7月, 2016 1 次提交
  5. 10 7月, 2016 4 次提交
    • E
      ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf() · 927265bc
      Eric Dumazet 提交于
      All inet6_netconf_notify_devconf() callers are in process context,
      so we can use GFP_KERNEL allocations if we take care of not holding
      a rwlock while not needed in ip6mr (we hold RTNL there)
      
      Fixes: d67b8c61 ("netconf: advertise mc_forwarding status")
      Fixes: f3a1bfb1 ("rtnl/ipv6: use netconf msg to advertise forwarding status")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      927265bc
    • E
      ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf() · fa17806c
      Eric Dumazet 提交于
      inet_forward_change() runs with RTNL held.
      We are allowed to sleep if required.
      
      If we use __in_dev_get_rtnl() instead of __in_dev_get_rcu(),
      we no longer have to use GFP_ATOMIC allocations in
      inet_netconf_notify_devconf(), meaning we are less likely to miss
      notifications under memory pressure, and wont touch precious memory
      reserves either and risk dropping incoming packets.
      
      inet_netconf_get_devconf() can also use GFP_KERNEL allocation.
      
      Fixes: edc9e748 ("rtnl/ipv4: use netconf msg to advertise forwarding status")
      Fixes: 9e551110 ("rtnl/ipv4: add support of RTM_GETNETCONF")
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fa17806c
    • D
      Merge branch 'bgmac-platform-device' · db9a1ba5
      David S. Miller 提交于
      Jon Mason says:
      
      ====================
      net: ethernet: bgmac: Add platform device support
      
      David Miller, Please consider including patches 1-5 in net-next
      
      Florian Fainelli, Please consider including patches 6 & 7 in
        devicetree/next
      
      Changes in v2:
      * Made device tree binding changes suggested by Sergei Shtylyov,
        Ray Jui, Rob Herring, Florian Fainelli, and Arnd Bergmann
      * Removed devm_* error paths in the bgmac_platform.c suggested by
        Florian Fainelli
      * Added Arnd Bergmann's Acked-by to the first 5 (there were changes
        outlined in the bullets above, but I believe them to be minor enough
        for him to not revoke his acks)
      
      This patch series adds support for other, non-bcma iProc SoC's to the
      bgmac driver.  This series only adds NSP support, but we are interested
      in adding support for the Cygnus and NS2 families (with more possible
      down the road).
      
      To support non-bcma enabled SoCs, we need to add the standard device
      tree "platform device" support.  Unfortunately, this driver is very
      tighly coupled with the bcma bus and much unwinding is needed.  I tried
      to break this up into a number of patches to make it more obvious what
      was being done to add platform device support.  I was able to verify
      that the bcma code still works using a 53012K board (NS SoC), and that
      the platform code works using a 58625K board (NSP SoC).
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      db9a1ba5
    • J
      net: ethernet: bgmac: Add platform device support · f6a95a24
      Jon Mason 提交于
      The bcma portion of the driver has been split off into a bcma specific
      driver.  This has been mirrored for the platform driver.  The last
      references to the bcma core struct have been changed into a generic
      function call.  These function calls are wrappers to either the original
      bcma code or new platform functions that access the same areas via MMIO.
      This necessitated adding function pointers for both platform and bcma to
      hide which backend is being used from the generic bgmac code.
      Signed-off-by: NJon Mason <jon.mason@broadcom.com>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f6a95a24