1. 28 Jun, 2019 24 commits
  2. 27 Jun, 2019 16 commits
    • David S. Miller's avatar
      Merge tag 'blk-dim-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · d7ee2878
      David S. Miller authored
      Saeed Mamameed says:
      
      ====================
      Generic DIM
      
      From: Tal Gilboa and Yamin Fridman
      
      Implement net DIM over a generic DIM library, add RDMA DIM
      
      dim.h lib exposes an implementation of the DIM algorithm for
      dynamically-tuned interrupt moderation for networking interfaces.
      
      We want a similar functionality for other protocols, which might need to
      optimize interrupts differently. Main motivation here is DIM for NVMf
      storage protocol.
      
      Current DIM implementation prioritizes reducing interrupt overhead over
      latency. Also, in order to reduce DIM's own overhead, the algorithm might
      take some time to identify it needs to change profiles. While this is
      acceptable for networking, it might not work well on other scenarios.
      
      Here we propose a new structure to DIM. The idea is to allow a slightly
      modified functionality without the risk of breaking Net DIM behavior for
      netdev. We verified there are no degradations in current DIM behavior with
      the modified solution.
      
      Suggested solution:
      - Common logic is implemented in lib/dim/dim.c
      - Net DIM (existing) logic is implemented in lib/dim/net_dim.c, which uses
        the common logic in dim.c
      - Any new DIM logic will be implemented in "lib/dim/new_dim.c".
        This new implementation will expose modified versions of profiles,
        dim_step() and dim_decision().
      - DIM API is declared in include/linux/dim.h for all implementations.
      
      Pros for this solution are:
      - Zero impact on existing net_dim implementation and usage
      - Relatively more code reuse (compared to two separate solutions)
      - Increased extensibility
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7ee2878
    • Christian Lamparter's avatar
      net: dsa: qca8k: introduce reset via gpio feature · a653f2f5
      Christian Lamparter authored
      The QCA8337(N) has a RESETn signal on Pin B42 that
      triggers a chip reset if the line is pulled low.
      The datasheet says that: "The active low duration
      must be greater than 10 ms".
      
      This can hopefully fix some of the issues related
      to pin strapping in OpenWrt for the EA8500 which
      suffers from detection issues after a SoC reset.
      
      Please note that the qca8k_probe() function does
      currently require to read the chip's revision
      register for identification purposes.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a653f2f5
    • Christian Lamparter's avatar
      dt-bindings: net: dsa: qca8k: document reset-gpios property · e7dd8a89
      Christian Lamparter authored
      This patch documents the qca8k's reset-gpios property that
      can be used if the QCA8337N ends up in a bad state during
      reset.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7dd8a89
    • David Ahern's avatar
      ipv6: Convert gateway validation to use fib6_info · b2c709cc
      David Ahern authored
      Gateway validation does not need a dst_entry, it only needs the fib
      entry to validate the gateway resolution and egress device. So,
      convert ip6_nh_lookup_table from ip6_pol_route to fib6_table_lookup
      and ip6_route_check_nh to use fib6_lookup over rt6_lookup.
      
      ip6_pol_route is a call to fib6_table_lookup and if successful a call
      to fib6_select_path. From there the exception cache is searched for an
      entry or a dst_entry is created to return to the caller. The exception
      entry is not relevant for gateway validation, so what matters are the
      calls to fib6_table_lookup and then fib6_select_path.
      
      Similarly, rt6_lookup can be replaced with a call to fib6_lookup with
      RT6_LOOKUP_F_IFACE set in flags. Again, the exception cache search is
      not relevant, only the lookup with path selection. The primary difference
      in the lookup paths is the use of rt6_select with fib6_lookup versus
      rt6_device_match with rt6_lookup. When you remove complexities in the
      rt6_select path, e.g.,
      1. saddr is not set for gateway validation, so RT6_LOOKUP_F_HAS_SADDR
         is not relevant
      2. rt6_check_neigh is not called so that removes the RT6_NUD_FAIL_DO_RR
         return and round-robin logic.
      
      the code paths are believed to be equivalent for the given use case -
      validate the gateway and optionally given the device. Furthermore, it
      aligns the validation with onlink code path and the lookup path actually
      used for rx and tx.
      
      Adjust the users, ip6_route_check_nh_onlink and ip6_route_check_nh to
      handle a fib6_info vs a rt6_info when performing validation checks.
      
      Existing selftests fib-onlink-tests.sh and fib_tests.sh are used to
      verify the changes.
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Reviewed-by: default avatarWei Wang <weiwan@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2c709cc
    • David S. Miller's avatar
      Merge branch 'FDB-VLAN-and-PTP-fixes-for-SJA1105-DSA' · 5b1bf3f6
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      FDB, VLAN and PTP fixes for SJA1105 DSA
      
      This patchset is an assortment of fixes for the net-next version of the
      sja1105 DSA driver:
      - Avoid a kernel panic when the driver fails to probe or unregisters
      - Finish Arnd Bermann's idea of compiling PTP support as part of the
        main DSA driver and not separately
      - Better handling of initial port-based VLAN as well as VLANs for
        dsa_8021q FDB entries
      - Fix address learning for the SJA1105 P/Q/R/S family
      - Make static FDB entries persistent across switch resets
      - Fix reporting of statically-added FDB entries in 'bridge fdb show'
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b1bf3f6
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Implement is_static for FDB entries on E/T · d7637782
      Vladimir Oltean authored
      The first generation switches don't tell us through the dynamic config
      interface whether the dumped FDB entries are static or not (the LOCKEDS
      bit from P/Q/R/S).
      
      However, now that we're keeping a mirror of all 'bridge fdb' commands in
      the static config, this is an opportunity to compare a dumped FDB entry
      to the driver's private database.  After all, what makes an entry static
      is that *we* added it.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d7637782
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Use correct dsa_8021q VIDs for FDB commands · b3ee526a
      Vladimir Oltean authored
      A FDB entry means that "frames that match this VID and DMAC must be
      forwarded to this port".
      
      In the case of dsa_8021q however, the VID is not a single one (and
      neither two, as my previous patch assumed). The VID can be set either by
      the CPU port (1 tx_vid), or by any of the other front-panel port (n-1
      rx_vid's).
      
      Fixes: 93647594 ("net: dsa: sja1105: Hide the dsa_8021q VLANs from the bridge fdb command")
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b3ee526a
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Populate is_static for FDB entries on P/Q/R/S · 17ae6555
      Vladimir Oltean authored
      The reason why this wasn't tackled earlier is that I had hoped I
      understood the user manual wrong.  But unfortunately hacks are required
      in order to retrieve the static/dynamic nature of FDB entries on SJA1105
      P/Q/R/S, since this info is stored in the writeback buffer of the
      dynamic config command.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      17ae6555
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add a high-level overview of the dynamic config interface · 4a950786
      Vladimir Oltean authored
      When trying to add support for LOCKEDS (static FDB entries) on SJA1105
      P/Q/R/S, at first I didn't remember how the abstraction I created
      worked, and actually thought it works by mistake.
      
      To avoid other people staring at the code and not making much sense out
      of it, add some comments at the top of the file.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4a950786
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Back up static FDB entries in kernel memory · 60f6053f
      Vladimir Oltean authored
      After commit 8456721d ("net: dsa: sja1105: Add support for
      configuring address ageing time"), we started to reset the switch rather
      often (each time the bridge core changes the ageing time on a switch
      port).
      
      The unfortunate reality is that SJA1105 doesn't have any {cold, warm,
      whatever} reset mode in which it accepts a new configuration stream
      without flushing the FDB.  Instead, in its world, the FDB *is* an
      optional part of the static configuration.
      
      So we play its game, and do what we also do for VLANs: for each 'bridge
      fdb' command, we add the FDB entry through the dynamic interface, and we
      append the in-kernel static config memory with info that we're going to
      use later, when the next reset command is going to be issued.
      
      The result is that 'bridge fdb' commands are now persistent (dynamically
      learned entries are lost, but that's ok).
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      60f6053f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Make P/Q/R/S learn MAC addresses · 6c56e167
      Vladimir Oltean authored
      At the end of the commit 1da73821 ("net: dsa: sja1105: Add FDB
      operations for P/Q/R/S series") message, I said that:
      
          At the moment only FDB entries installed statically through 'bridge fdb'
          are visible in the dump callback - the dynamically learned ones are
          still under investigation.
      
      It looks like the reason why they were not visible in 'bridge fdb' was
      that they were never learned - always flooded.
      
      SJA1105 P/Q/R/S manual says about the MAXADDRP[port] field:
      
          Specify the maximum number of MAC address dynamically learned from
          the respective port. It is used to limit the number of learned MAC
          addresses per port.
      
      It looks like not providing a value in the static config (aka providing
      zeroes) is enough for it to not store the learned addresses in the FDB.
      
      For now we divide the 1024 entry FDB "equally" amongst the 5 ports. This
      may be revisited if the situation calls for that - for now I'm happy
      that learning works.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c56e167
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Actually implement the P/Q/R/S FDB bits · 0803948e
      Vladimir Oltean authored
      In commit 1da73821 ("net: dsa: sja1105: Add FDB operations for
      P/Q/R/S series"), these bits were set in the static config, but
      apparently they did not do anything.  The reason is that the packing
      accessors for them were part of a patch I forgot to send.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0803948e
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Make vid 1 the default pvid · e3502b82
      Vladimir Oltean authored
      In SJA1105 there is no concept of 'default values' per se, everything
      needs to be driver-supplied through the static configuration tables.
      
      The issue is that the hardware manual says that 'at least the default
      untagging VLAN' is mandatory to be provided through the static config.
      But VLAN 0 isn't a very good initial pvid - its use is reserved for
      priority-tagged frames, and the layers of the stack that care about
      those already make sure that this VLAN is installed, as can be seen in
      the message below:
      
        8021q: adding VLAN 0 to HW filter on device swp2
      
      So change the pvid provided through the static configuration to 1, which
      matches the bridge core's defaults.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e3502b82
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Cancel PTP delayed work on unregister · 29dd908d
      Vladimir Oltean authored
      Currently when the driver unloads and PTP is enabled, the delayed work
      that prevents the timecounter from expiring becomes a ticking time bomb.
      The kernel will schedule the work thread within 60 seconds of driver
      removal, but the work handler is no longer there, leading to this
      strange and inconclusive stack trace:
      
      [   64.473112] Unable to handle kernel paging request at virtual address 79746970
      [   64.480340] pgd = 008c4af9
      [   64.483042] [79746970] *pgd=00000000
      [   64.486620] Internal error: Oops: 80000005 [#1] SMP ARM
      [   64.491820] Modules linked in:
      [   64.494871] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-rc5-01634-ge3a2773ba9e5 #1246
      [   64.503007] Hardware name: Freescale LS1021A
      [   64.507259] PC is at 0x79746970
      [   64.510393] LR is at call_timer_fn+0x3c/0x18c
      [   64.514729] pc : [<79746970>]    lr : [<c03bd734>]    psr: 60010113
      [   64.520965] sp : c1901de0  ip : 00000000  fp : c1903080
      [   64.526163] r10: c1901e38  r9 : ffffe000  r8 : c19064ac
      [   64.531363] r7 : 79746972  r6 : e98dd260  r5 : 00000100  r4 : c1a9e4a0
      [   64.537859] r3 : c1900000  r2 : ffffa400  r1 : 79746972  r0 : e98dd260
      [   64.544359] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [   64.551460] Control: 10c5387d  Table: a8a2806a  DAC: 00000051
      [   64.557176] Process swapper/0 (pid: 0, stack limit = 0x1ddb27f0)
      [   64.563147] Stack: (0xc1901de0 to 0xc1902000)
      [   64.567481] 1de0: eb6a4918 3d60d7c3 c1a9e554 e98dd260 eb6a34c0 c1a9e4a0 ffffa400 c19064ac
      [   64.575616] 1e00: ffffe000 c03bd95c c1901e34 c1901e34 eb6a34c0 c1901e30 c1903d00 c186f4c0
      [   64.583751] 1e20: c1906488 29e34000 c1903080 c03bdca4 00000000 eaa6f218 00000000 eb6a45c0
      [   64.591886] 1e40: eb6a45c0 20010193 00000003 c03c0a68 20010193 3f7231be c1903084 00000002
      [   64.600022] 1e60: 00000082 00000001 ffffe000 c1a9e0a4 00000100 c0302298 02b64722 0000000f
      [   64.608157] 1e80: c186b3c8 c1877540 c19064ac 0000000a c186b350 ffffa401 c1903d00 c1107348
      [   64.616292] 1ea0: 00200102 c0d87a14 ea823c00 ffffe000 00000012 00000000 00000000 ea810800
      [   64.624427] 1ec0: f0803000 c1876ba8 00000000 c034c784 c18774b8 c039fb50 c1906c90 c1978aac
      [   64.632562] 1ee0: f080200c f0802000 c1901f10 c0709ca8 c03091a0 60010013 ffffffff c1901f44
      [   64.640697] 1f00: 00000000 c1900000 c1876ba8 c0301a8c 00000000 000070a0 eb6ac1a0 c031da60
      [   64.648832] 1f20: ffffe000 c19064ac c19064f0 00000001 00000000 c1906488 c1876ba8 00000000
      [   64.656967] 1f40: ffffffff c1901f60 c030919c c03091a0 60010013 ffffffff 00000051 00000000
      [   64.665102] 1f60: ffffe000 c0376aa4 c1a9da37 ffffffff 00000037 3f7231be c1ab20c0 000000cc
      [   64.673238] 1f80: c1906488 c1906480 ffffffff 00000037 c1ab20c0 c1ab20c0 00000001 c0376e1c
      [   64.681373] 1fa0: c1ab2118 c1700ea8 ffffffff ffffffff 00000000 c1700754 c17dfa40 ebfffd80
      [   64.689509] 1fc0: 00000000 c17dfa40 3f7733be 00000000 00000000 c1700330 00000051 10c0387d
      [   64.697644] 1fe0: 00000000 8f000000 410fc075 10c5387d 00000000 00000000 00000000 00000000
      [   64.705788] [<c03bd734>] (call_timer_fn) from [<c03bd95c>] (expire_timers+0xd8/0x144)
      [   64.713579] [<c03bd95c>] (expire_timers) from [<c03bdca4>] (run_timer_softirq+0xe4/0x1dc)
      [   64.721716] [<c03bdca4>] (run_timer_softirq) from [<c0302298>] (__do_softirq+0x130/0x3c8)
      [   64.729854] [<c0302298>] (__do_softirq) from [<c034c784>] (irq_exit+0xbc/0xd8)
      [   64.737040] [<c034c784>] (irq_exit) from [<c039fb50>] (__handle_domain_irq+0x60/0xb4)
      [   64.744833] [<c039fb50>] (__handle_domain_irq) from [<c0709ca8>] (gic_handle_irq+0x58/0x9c)
      [   64.753143] [<c0709ca8>] (gic_handle_irq) from [<c0301a8c>] (__irq_svc+0x6c/0x90)
      [   64.760583] Exception stack(0xc1901f10 to 0xc1901f58)
      [   64.765605] 1f00:                                     00000000 000070a0 eb6ac1a0 c031da60
      [   64.773740] 1f20: ffffe000 c19064ac c19064f0 00000001 00000000 c1906488 c1876ba8 00000000
      [   64.781873] 1f40: ffffffff c1901f60 c030919c c03091a0 60010013 ffffffff
      [   64.788456] [<c0301a8c>] (__irq_svc) from [<c03091a0>] (arch_cpu_idle+0x38/0x3c)
      [   64.795816] [<c03091a0>] (arch_cpu_idle) from [<c0376aa4>] (do_idle+0x1bc/0x298)
      [   64.803175] [<c0376aa4>] (do_idle) from [<c0376e1c>] (cpu_startup_entry+0x18/0x1c)
      [   64.810707] [<c0376e1c>] (cpu_startup_entry) from [<c1700ea8>] (start_kernel+0x480/0x4ac)
      [   64.818839] Code: bad PC value
      [   64.821890] ---[ end trace e226ed97b1c584cd ]---
      [   64.826482] Kernel panic - not syncing: Fatal exception in interrupt
      [   64.832807] CPU1: stopping
      [   64.835501] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G      D           5.2.0-rc5-01634-ge3a2773ba9e5 #1246
      [   64.845013] Hardware name: Freescale LS1021A
      [   64.849266] [<c0312394>] (unwind_backtrace) from [<c030cc74>] (show_stack+0x10/0x14)
      [   64.856972] [<c030cc74>] (show_stack) from [<c0ff4138>] (dump_stack+0xb4/0xc8)
      [   64.864159] [<c0ff4138>] (dump_stack) from [<c0310854>] (handle_IPI+0x3bc/0x3dc)
      [   64.871519] [<c0310854>] (handle_IPI) from [<c0709ce8>] (gic_handle_irq+0x98/0x9c)
      [   64.879050] [<c0709ce8>] (gic_handle_irq) from [<c0301a8c>] (__irq_svc+0x6c/0x90)
      [   64.886489] Exception stack(0xea8cbf60 to 0xea8cbfa8)
      [   64.891514] bf60: 00000000 0000307c eb6c11a0 c031da60 ffffe000 c19064ac c19064f0 00000002
      [   64.899649] bf80: 00000000 c1906488 c1876ba8 00000000 00000000 ea8cbfb0 c030919c c03091a0
      [   64.907780] bfa0: 600d0013 ffffffff
      [   64.911250] [<c0301a8c>] (__irq_svc) from [<c03091a0>] (arch_cpu_idle+0x38/0x3c)
      [   64.918609] [<c03091a0>] (arch_cpu_idle) from [<c0376aa4>] (do_idle+0x1bc/0x298)
      [   64.925967] [<c0376aa4>] (do_idle) from [<c0376e1c>] (cpu_startup_entry+0x18/0x1c)
      [   64.933496] [<c0376e1c>] (cpu_startup_entry) from [<803025cc>] (0x803025cc)
      [   64.940422] Rebooting in 3 seconds..
      
      In this case, what happened is that the DSA driver failed to probe at
      boot time due to a PHY issue during phylink_connect_phy:
      
      [    2.245607] fsl-gianfar soc:ethernet@2d90000 eth2: error -19 setting up slave phy
      [    2.258051] sja1105 spi0.1: failed to create slave for port 0.0
      
      Fixes: bb77f36a ("net: dsa: sja1105: Add support for the PTP clock")
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29dd908d
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Build PTP support in main DSA driver · 3d64ea38
      Vladimir Oltean authored
      As Arnd Bergmann pointed out in commit 78fe8a28 ("net: dsa: sja1105:
      fix ptp link error"), there is no point in having PTP support as a
      separate loadable kernel module.
      
      So remove the exported symbols and make sja1105.ko contain PTP support
      or not based on CONFIG_NET_DSA_SJA1105_PTP.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Acked-by: default avatarWillem de Bruijn <willemb@google.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3d64ea38
    • David S. Miller's avatar
      Merge branch 'net-dsa-microchip-Convert-to-regmap' · c881e10e
      David S. Miller authored
      Marek Vasut says:
      
      ====================
      net: dsa: microchip: Convert to regmap
      
      This patchset converts KSZ9477 switch driver to regmap.
      
      This was tested with extra patches on KSZ8795. This was also tested
      on KSZ9477 on Microchip KSZ9477EVB board, which I now have.
      ====================
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      c881e10e