Skip to content
  1. Jul 13, 2016
  2. Jul 12, 2016
  3. Jul 11, 2016
  4. Jul 10, 2016
    • Eric Dumazet's avatar
      ipv6: do not abuse GFP_ATOMIC in inet6_netconf_notify_devconf() · 927265bc
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      927265bc
    • Eric Dumazet's avatar
      ipv4: do not abuse GFP_ATOMIC in inet_netconf_notify_devconf() · fa17806c
      Eric Dumazet authored
      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: default avatarEric Dumazet <edumazet@google.com>
      Cc: Nicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: default avatarNicolas Dichtel <nicolas.dichtel@6wind.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa17806c
    • David S. Miller's avatar
      Merge branch 'bgmac-platform-device' · db9a1ba5
      David S. Miller authored
      
      
      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: default avatarDavid S. Miller <davem@davemloft.net>
      db9a1ba5
    • Jon Mason's avatar
      net: ethernet: bgmac: Add platform device support · f6a95a24
      Jon Mason authored
      
      
      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: default avatarJon Mason <jon.mason@broadcom.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f6a95a24
    • Jon Mason's avatar
      net: ethernet: bgmac: convert to feature flags · db791eb2
      Jon Mason authored
      
      
      The bgmac driver is using the bcma provides device ID and revision, as
      well as the SoC ID and package, to determine which features are
      necessary to enable, reset, etc in the driver.   In anticipation of
      removing the bcma requirement for this driver, these must be changed to
      not reference that struct.  In place of that, each "feature" has been
      given a flag, and the flags are enabled for their respective device and
      SoC.
      
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      db791eb2
    • Jon Mason's avatar
      net: ethernet: bgmac: move BCMA MDIO Phy code into a separate file · 55954f3b
      Jon Mason authored
      
      
      Move the BCMA MDIO phy into a separate file, as it is very tightly
      coupled with the BCMA bus.  This will help with the upcoming BCMA
      removal from the bgmac driver.  Optimally, this should be moved into
      phy drivers, but it is too tightly coupled with the bgmac driver to
      effectively move it without more changes to the driver.
      
      Note: the phy_reset was intentionally removed, as the mdio phy subsystem
      automatically resets the phy if a reset function pointer is present.  In
      addition to the moving of the driver, this reset function is added.
      
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      55954f3b
    • Jon Mason's avatar
      net: ethernet: bgmac: add dma_dev pointer · a0b68486
      Jon Mason authored
      
      
      The dma buffer allocation, etc references a dma_dev device pointer from
      the bcma core.  In anticipation of removing the bcma requirement for
      this driver, these must be changed to not reference that struct.  Add a
      dma_dev device pointer to the bgmac stuct and reference that instead.
      
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a0b68486
    • Jon Mason's avatar
      net: ethernet: bgmac: change bgmac_* prints to dev_* prints · d00a8281
      Jon Mason authored
      
      
      The bgmac_* print wrappers call dev_* prints with the dev pointer from
      the bcma core.  In anticipation of removing the bcma requirement for
      this driver, these must be changed to not reference that struct.  So,
      simply change all of the bgmac_* prints to their dev_* counterparts.  In
      some cases netdev_* prints are more appropriate, so change those as
      well.
      
      Signed-off-by: default avatarJon Mason <jon.mason@broadcom.com>
      Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Tested-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d00a8281
    • Jesper Dangaard Brouer's avatar
      net: tracepoint napi:napi_poll add work and budget · 1db19db7
      Jesper Dangaard Brouer authored
      
      
      An important information for the napi_poll tracepoint is knowing
      the work done (packets processed) by the napi_poll() call. Add
      both the work done and budget, as they are related.
      
      Handle trace_napi_poll() param change in dropwatch/drop_monitor
      and in python perf script netdev-times.py in backward compat way,
      as python fortunately supports optional parameter handling.
      
      Signed-off-by: default avatarJesper Dangaard Brouer <brouer@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1db19db7
    • David S. Miller's avatar
      Merge branch 'r8152-next' · 89141e1c
      David S. Miller authored
      
      
      Hayes Wang says:
      
      ====================
      r8152: remove the redundant code
      
      Remove the unnacessary code.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      89141e1c
    • hayeswang's avatar
      r8152: remove cancel_delayed_work_sync in rtl8152_set_speed · c23d86ae
      hayeswang authored
      
      
      There is no conflict between the work_queue function and
      rtl8152_set_speed(), so we don't have to cancel the delayed work in
      rtl8152_set_speed().
      
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c23d86ae
    • hayeswang's avatar
      r8152: remove a netif_carrier_off in rtl8152_open function · c79262f3
      hayeswang authored
      After commit 90186af4
      
       ("r8152: fix lockup when runtime PM is enabled"),
      the autoresume wouldn't start the device before rtl8152_open() is finished.
      Therefore, we don't have to reset the linking status before and after
      autoresume. That is, one of netif_carrier_off() in rtl8152_open() could be
      removed.
      
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c79262f3
    • hayeswang's avatar
      r8152: remove rtl_phy_reset function · b1648066
      hayeswang authored
      
      
      In rtl_hw_phy_work_func_t(), the flag of PHY_RESET is set in
      rtl_ops.hw_phy_cfg() and cleared in rtl8152_set_speed(). Therefore,
      the rtl_phy_reset() is never run and is unnecessary.
      
      Signed-off-by: default avatarHayes Wang <hayeswang@realtek.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b1648066
    • David S. Miller's avatar
      Merge branch 'mpls-in-ipv4-and-udp' · fb577316
      David S. Miller authored
      
      
      Simon Horman says:
      
      ====================
      net: support MPLS in IPv4 and UDP
      
      This short series provides support for MPLS in IPv4 (RFC4023), and by
      virtue of FOU, MPLS in UDP (RFC7510).
      
      The changes are as follows:
      1. Teach tunnel4.c about AF_MPLS, it already understands AF_INET and
         AF_INET6
      2. Enhance IPIP and SIT to handle MPLS. Both already handle IPv4.
         SIT also already handles IPv6.
      3. Trivially enhance MPLS to allow routes over SIT and IPIP tunnels.
      
      A corresponding patch set for iproute2 has also been provided.
      
      Changes since v1
      * Correct inverted IPIP protocol logic in SIT patch
      * Provide usage example below
      
      Sample configuration follows:
      
      * The following creates a tunnel and routes MPLS packets whose outermost
        label is 100 over it. The forwarded packets will have the outermost label
        stack entry, 100, removed and two label stack entries added, the
        outermost having label 200 and the next having label 300.
      
        The local end-point for the tunnel is 10.0.99.192 and the remote
        endpoint is 10.0.99.193.
      
        The local address for encapsulated packets is 10.0.98.192 and the
        remote address is 10.0.98.193.
      
        # Create an MPLS over IPv4 tunnel using the IPIP driver
        ip link add name tun1 type ipip remote 10.0.99.193 local 10.0.99.192 \
      	ttl 225 mode mplsip
      
        # Bring the tunnel up and an add an IPv4 address and route
        ip link set up dev tun1
        ip addr add 10.0.98.192/24 dev tun1
      
        # Set MPLS route
        # Allow MPLS forwarding of packets recieved on eth0
        echo 1 > /proc/sys/net/mpls/conf/eth0/input
        # Larger than label to be routed (100)
        echo 101 > /proc/sys/net/mpls/platform_labels
        ip -f mpls route add 100 as 200/300 via inet 10.0.98.193
      
      * For FOU (in this case MPLS over UDP) a tunnel may created using:
      
        # Packets recieved on UDP port 6635 are MPLS over UDP (IP proto 137)
        ip fou add port 6635 ipproto 137
        # Create the tunnel netdev
        ip link add name tun1 type ipip remote 10.0.99.193 local 10.0.99.192 \
      	ttl 225 mode mplsip encap fou encap-sport auto encap-dport 6635
      
        IPv4 address, link and route, and MPLS routing commands are as per
        the MPLS over IPv4 example
      
      * To use the SIT driver instead of the IPIP driver "ipip" may be substituted
        for "sit" in the above examples.
      
      * To create a tunnel that forwards and receives all supported
        inner-protocols "mplsip" may be substituted for "any" in the above
        examples.
      
        For the IPIP driver this configures both IPv4 and MPLS over IPv4.
        For the SIT driver this configures IPv6, IPv4 and MPLS over IPv4.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fb577316