1. 20 3月, 2020 1 次提交
  2. 16 3月, 2020 7 次提交
  3. 15 3月, 2020 1 次提交
  4. 12 3月, 2020 1 次提交
  5. 11 3月, 2020 2 次提交
  6. 10 3月, 2020 1 次提交
  7. 05 3月, 2020 2 次提交
    • V
      net: dsa: felix: Allow unknown unicast traffic towards the CPU port module · 1cf3299b
      Vladimir Oltean 提交于
      Compared to other DSA switches, in the Ocelot cores, the RX filtering is
      a much more important concern.
      
      Firstly, the primary use case for Ocelot is non-DSA, so there isn't any
      secondary Ethernet MAC [the DSA master's one] to implicitly drop frames
      having a DMAC we are not interested in.  So the switch driver itself
      needs to install FDB entries towards the CPU port module (PGID_CPU) for
      the MAC address of each switch port, in each VLAN installed on the port.
      Every address that is not whitelisted is implicitly dropped. This is in
      order to achieve a behavior similar to N standalone net devices.
      
      Secondly, even in the secondary use case of DSA, such as illustrated by
      Felix with the NPI port mode, that secondary Ethernet MAC is present,
      but its RX filter is bypassed. This is because the DSA tags themselves
      are placed before Ethernet, so the DMAC that the switch ports see is
      not seen by the DSA master too (since it's shifter to the right).
      
      So RX filtering is pretty important. A good RX filter won't bother the
      CPU in case the switch port receives a frame that it's not interested
      in, and there exists no other line of defense.
      
      Ocelot is pretty strict when it comes to RX filtering: non-IP multicast
      and broadcast traffic is allowed to go to the CPU port module, but
      unknown unicast isn't. This means that traffic reception for any other
      MAC addresses than the ones configured on each switch port net device
      won't work. This includes use cases such as macvlan or bridging with a
      non-Ocelot (so-called "foreign") interface. But this seems to be fine
      for the scenarios that the Linux system embedded inside an Ocelot switch
      is intended for - it is simply not interested in unknown unicast
      traffic, as explained in Allan Nielsen's presentation [0].
      
      On the other hand, the Felix DSA switch is integrated in more
      general-purpose Linux systems, so it can't afford to drop that sort of
      traffic in hardware, even if it will end up doing so later, in software.
      
      Actually, unknown unicast means more for Felix than it does for Ocelot.
      Felix doesn't attempt to perform the whitelisting of switch port MAC
      addresses towards PGID_CPU at all, mainly because it is too complicated
      to be feasible: while the MAC addresses are unique in Ocelot, by default
      in DSA all ports are equal and inherited from the DSA master. This adds
      into account the question of reference counting MAC addresses (delayed
      ocelot_mact_forget), not to mention reference counting for the VLAN IDs
      that those MAC addresses are installed in. This reference counting
      should be done in the DSA core, and the fact that it wasn't needed so
      far is due to the fact that the other DSA switches don't have the DSA
      tag placed before Ethernet, so the DSA master is able to whitelist the
      MAC addresses in hardware.
      
      So this means that even regular traffic termination on a Felix switch
      port happens through flooding (because neither Felix nor Ocelot learn
      source MAC addresses from CPU-injected frames).
      
      So far we've explained that whitelisting towards PGID_CPU:
      - helps to reduce the likelihood of spamming the CPU with frames it
        won't process very far anyway
      - is implemented in the ocelot driver
      - is sufficient for the ocelot use cases
      - is not feasible in DSA
      - breaks use cases in DSA, in the current status (whitelisting enabled
        but no MAC address whitelisted)
      
      So the proposed patch allows unknown unicast frames to be sent to the
      CPU port module. This is done for the Felix DSA driver only, as Ocelot
      seems to be happy without it.
      
      [0]: https://www.youtube.com/watch?v=B1HhxEcU7JgSuggested-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1cf3299b
    • V
      net: mscc: ocelot: eliminate confusion between CPU and NPI port · 69df578c
      Vladimir Oltean 提交于
      Ocelot has the concept of a CPU port. The CPU port is represented in the
      forwarding and the queueing system, but it is not a physical device. The
      CPU port can either be accessed via register-based injection/extraction
      (which is the case of Ocelot), via Frame-DMA (similar to the first one),
      or "connected" to a physical Ethernet port (called NPI in the datasheet)
      which is the case of the Felix DSA switch.
      
      In Ocelot the CPU port is at index 11.
      In Felix the CPU port is at index 6.
      
      The CPU bit is treated special in the forwarding, as it is never cleared
      from the forwarding port mask (once added to it). Other than that, it is
      treated the same as a normal front port.
      
      Both Felix and Ocelot should use the CPU port in the same way. This
      means that Felix should not use the NPI port directly when forwarding to
      the CPU, but instead use the CPU port.
      
      This patch is fixing this such that Felix will use port 6 as its CPU
      port, and just use the NPI port to carry the traffic.
      
      Therefore, eliminate the "ocelot->cpu" variable which was holding the
      index of the NPI port for Felix, and the index of the CPU port module
      for Ocelot, so the variable was actually configuring different things
      for different drivers and causing at least part of the confusion.
      
      Also remove the "ocelot->num_cpu_ports" variable, which is the result of
      another confusion. The 2 CPU ports mentioned in the datasheet are
      because there are two frame extraction channels (register based or DMA
      based). This is of no relevance to the driver at the moment, and
      invisible to the analyzer module.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Suggested-by: NAllan W. Nielsen <allan.nielsen@microchip.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      69df578c
  8. 04 3月, 2020 2 次提交
  9. 01 3月, 2020 2 次提交
    • V
      net: dsa: sja1105: Don't destroy not-yet-created xmit_worker · 52c0d4e3
      Vladimir Oltean 提交于
      Fixes the following NULL pointer dereference on PHY connect error path
      teardown:
      
      [    2.291010] sja1105 spi0.1: Probed switch chip: SJA1105T
      [    2.310044] sja1105 spi0.1: Enabled switch tagging
      [    2.314970] fsl-gianfar soc:ethernet@2d90000 eth2: error -19 setting up slave phy
      [    2.322463] 8<--- cut here ---
      [    2.325497] Unable to handle kernel NULL pointer dereference at virtual address 00000018
      [    2.333555] pgd = (ptrval)
      [    2.336241] [00000018] *pgd=00000000
      [    2.339797] Internal error: Oops: 5 [#1] SMP ARM
      [    2.344384] Modules linked in:
      [    2.347420] CPU: 1 PID: 64 Comm: kworker/1:1 Not tainted 5.5.0-rc5 #1
      [    2.353820] Hardware name: Freescale LS1021A
      [    2.358070] Workqueue: events deferred_probe_work_func
      [    2.363182] PC is at kthread_destroy_worker+0x4/0x74
      [    2.368117] LR is at sja1105_teardown+0x70/0xb4
      [    2.372617] pc : [<c036cdd4>]    lr : [<c0b89238>]    psr: 60000013
      [    2.378845] sp : eeac3d30  ip : eeab1900  fp : eef45480
      [    2.384036] r10: eef4549c  r9 : 00000001  r8 : 00000000
      [    2.389227] r7 : eef527c0  r6 : 00000034  r5 : ed8ddd0c  r4 : ed8ddc40
      [    2.395714] r3 : 00000000  r2 : 00000000  r1 : eef4549c  r0 : 00000000
      [    2.402204] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [    2.409297] Control: 10c5387d  Table: 8020406a  DAC: 00000051
      [    2.415008] Process kworker/1:1 (pid: 64, stack limit = 0x(ptrval))
      [    2.421237] Stack: (0xeeac3d30 to 0xeeac4000)
      [    2.612635] [<c036cdd4>] (kthread_destroy_worker) from [<c0b89238>] (sja1105_teardown+0x70/0xb4)
      [    2.621379] [<c0b89238>] (sja1105_teardown) from [<c10717fc>] (dsa_switch_teardown.part.1+0x48/0x74)
      [    2.630467] [<c10717fc>] (dsa_switch_teardown.part.1) from [<c1072438>] (dsa_register_switch+0x8b0/0xbf4)
      [    2.639984] [<c1072438>] (dsa_register_switch) from [<c0b89c30>] (sja1105_probe+0x2ac/0x464)
      [    2.648378] [<c0b89c30>] (sja1105_probe) from [<c0b11a5c>] (spi_drv_probe+0x7c/0xa0)
      [    2.656081] [<c0b11a5c>] (spi_drv_probe) from [<c0a26ab8>] (really_probe+0x208/0x480)
      [    2.663871] [<c0a26ab8>] (really_probe) from [<c0a26f0c>] (driver_probe_device+0x78/0x1c4)
      [    2.672093] [<c0a26f0c>] (driver_probe_device) from [<c0a24c48>] (bus_for_each_drv+0x80/0xc4)
      [    2.680574] [<c0a24c48>] (bus_for_each_drv) from [<c0a26810>] (__device_attach+0xd0/0x168)
      [    2.688794] [<c0a26810>] (__device_attach) from [<c0a259d8>] (bus_probe_device+0x84/0x8c)
      [    2.696927] [<c0a259d8>] (bus_probe_device) from [<c0a25f24>] (deferred_probe_work_func+0x84/0xc4)
      [    2.705842] [<c0a25f24>] (deferred_probe_work_func) from [<c03667b0>] (process_one_work+0x22c/0x560)
      [    2.714926] [<c03667b0>] (process_one_work) from [<c0366d8c>] (worker_thread+0x2a8/0x5d4)
      [    2.723059] [<c0366d8c>] (worker_thread) from [<c036cf94>] (kthread+0x150/0x154)
      [    2.730416] [<c036cf94>] (kthread) from [<c03010e8>] (ret_from_fork+0x14/0x2c)
      
      Checking for NULL pointer is correct because the per-port xmit kernel
      threads are created in sja1105_probe immediately after calling
      dsa_register_switch.
      
      Fixes: a68578c2 ("net: dsa: Make deferred_xmit private to sja1105")
      Signed-off-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      52c0d4e3
    • R
      net: dsa: mv88e6xxx: fix lockup on warm boot · 0395823b
      Russell King 提交于
      If the switch is not hardware reset on a warm boot, interrupts can be
      left enabled, and possibly pending. This will cause us to enter an
      infinite loop trying to service an interrupt we are unable to handle,
      thereby preventing the kernel from booting.
      
      Ensure that the global 2 interrupt sources are disabled before we claim
      the parent interrupt.
      
      Observed on the ZII development revision B and C platforms with
      reworked serdes support, and using reboot -f to reboot the platform.
      
      Fixes: dc30c35b ("net: dsa: mv88e6xxx: Implement interrupt support.")
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0395823b
  10. 28 2月, 2020 3 次提交
  11. 27 2月, 2020 3 次提交
  12. 25 2月, 2020 1 次提交
  13. 17 2月, 2020 5 次提交
  14. 10 2月, 2020 1 次提交
  15. 08 2月, 2020 1 次提交
  16. 07 2月, 2020 2 次提交
  17. 20 1月, 2020 1 次提交
  18. 19 1月, 2020 2 次提交
  19. 17 1月, 2020 2 次提交