target/linux/layerscape/patches-5.4/701-net-0367-net-mscc-ocelot-Workaround-to-allow-traffic-to-CPU-i.patch

   1 From 937bf9496489cb4b491e75fe4436348bf3454dcd Mon Sep 17 00:00:00 2001
   2 From: Vladimir Oltean <vladimir.oltean@nxp.com>
   3 Date: Sat, 21 Dec 2019 23:19:20 +0200
   4 Subject: [PATCH] net: mscc: ocelot: Workaround to allow traffic to CPU in
   5  standalone mode
   6
   7 The Ocelot switches have what is, in my opinion, a design flaw: their
   8 DSA header is in front of the Ethernet header, which means that they
   9 subvert the DSA master's RX filter, which for all practical purposes,
  10 either needs to be in promiscuous mode, or the OCELOT_TAG_PREFIX_LONG
  11 needs to be used for extraction, which makes the switch add a fake DMAC
  12 of ff:ff:ff:ff:ff:ff so that the DSA master accepts the frame.
  13
  14 The issue with this design, of course, is that the CPU will be spammed
  15 with frames that it doesn't want to respond to, and there isn't any
  16 hardware offload in place by default to drop them.
  17
  18 What is being done in the VSC7514 Ocelot driver is a process of
  19 selective whitelisting. The "MAC address" of each Ocelot switch net
  20 device, with all VLANs installed on that port, is being added as a FDB
  21 entry towards PGID_CPU.
  22
  23 Some background first: Port Group IDs (PGIDs) are masks of destination
  24 ports. The switch performs 3 lookups in the PGID table for each frame,
  25 and forwards the frame to the ports that are present in the logical AND
  26 of all 3 PGIDs (for the most part, see below).
  27
  28 The first PGID lookup is for the destination masks and the PGID table is
  29 indexed by the DEST_IDX field from the MAC table (FDB).
  30 The PGID can be an unicast set: PGIDs 0-11 are the per-port PGIDs, and
  31 by convention PGID i has only BIT(i) set, aka only this port is set in
  32 the destination mask.
  33 Or the PGID can be a multicast set: PGIDs 12-63 can (again, still by
  34 convention) hold a richer destination mask comprised of multiple ports.
  35
  36 [ Ignoring the second PGID lookup, for aggregation, since it doesn't
  37   interfere. ]
  38
  39 The third PGID lookup is for source masks: PGID entries 80-91 answer the
  40 question: is port i allowed to forward traffic to port j? If yes, then
  41 BIT(j) of PGID 80+i will be found set.
  42
  43 What is interesting about the CPU port in this whole story is that, in
  44 the way the driver sets up the PGIDs, its bit isn't set in any source
  45 mask PGID of any other port (therefore, the third lookup would always
  46 decide to exclude the CPU port from this list). So frames are never
  47 _forwarded_ to the CPU.
  48
  49 There is a loophole in this PGID mechanism which is described in the
  50 VSC7514 manual:
  51
  52         If an entry is found in the MAC table entry of ENTRY_TYPE 0 or 1
  53         and the CPU port is set in the PGID pointed to by the MAC table
  54         entry, CPU extraction queue PGID.DST_PGID is added to the CPUQ.
  55
  56 In other words, the CPU port is special, and frames are "copied" to the
  57 CPU, disregarding the source masks (third PGID lookup), if BIT(cpu) is
  58 found to be set in the destination masks (first PGID lookup).
  59
  60 Now back to the story: what is PGID_CPU? It is a multicast set
  61 containing only BIT(cpu). I don't know why it was chosen to be a
  62 multicast PGID (59) and not simply the unicast one of this port, but it
  63 doesn't matter.
  64
  65 The point is that frames that match the FDB will go to PGID_CPU by
  66 virtue of the DEST_IDX from the respective MAC table entry, and frames
  67 that don't will go to PGID_UC or PGID_MC, by virtue of the FLD_UNICAST,
  68 FLD_BROADCAST etc settings for flooding. And that is where the
  69 distinction is made: flooded frames will be subject to the third PGID
  70 lookup, while frames that are whitelisted to the PGID_CPU by the MAC
  71 table aren't.
  72
  73 So we can use this mechanism to simulate an RX filter, given that we are
  74 subverting the DSA master's implicit one, as mentioned in the first
  75 paragraph. But this has some limitations:
  76
  77 - In Ocelot each net device has its own MAC address. When simulating
  78   this with MAC table entries, it will practically result in having N
  79   MAC addresses for each of the N front-panel ports (because FDB entries
  80   are not per source port). A bit strange, I think.
  81
  82 - In DSA we don't have the infrastructure in place to support this
  83   whitelisting mechanism. Calling .port_fdb_add on the CPU port for each
  84   slave net device dev_addr isn't, in itself, hard. The problem is with
  85   the VLANs that this port is part of. We would need to keep a duplicate
  86   list of the VLANs from the bridge, plus the ones added from 8021q, for
  87   each port. And we would need reference counting on each MAC address,
  88   such that when a front-panel port changes its MAC address and we need
  89   to delete the old FDB entry, we don't actually delete it if the other
  90   front-panel ports are still using it. Not to mention that this FDB
  91   entry would have to be added on the whole net of upstream DSA switches.
  92
  93 So... it's complicated. What this patch does is to simply allow frames
  94 to be flooded to the CPU, which is anyway what the Ocelot driver is
  95 doing after removing the bridge from the net devices, see this snippet
  96 from ocelot_bridge_stp_state_set:
  97
  98         /* Apply FWD mask. The loop is needed to add/remove the current port as
  99          * a source for the other ports.
 100          */
 101         for (p = 0; p < ocelot->num_phys_ports; p++) {
 102                 if (p == ocelot->cpu || (ocelot->bridge_fwd_mask & BIT(p))) {
 103                         (...)
 104                 } else {
 105                         /* Only the CPU port, this is compatible with link
 106                          * aggregation.
 107                          */
 108                         ocelot_write_rix(ocelot,
 109                                          BIT(ocelot->cpu),
 110                                          ANA_PGID_PGID, PGID_SRC + p);
 111                 }
 112
 113 Otherwise said, the ocelot driver itself is already not self-coherent,
 114 since immediately after probe time, and immediately after removal from a
 115 bridge, it behaves in different ways, although the front panel ports are
 116 standalone in both cases.
 117
 118 While standalone traffic _does_ work for the Felix DSA wrapper after
 119 enslaving and removing the ports from a bridge, this patch makes
 120 standalone traffic work at probe time too, with the caveat that even
 121 irrelevant frames will get processed by software, making it more
 122 susceptible to denial of service.
 123
 124 Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
 125 ---
 126  drivers/net/ethernet/mscc/ocelot.c | 12 ++++++++++++
 127  1 file changed, 12 insertions(+)
 128
 129 --- a/drivers/net/ethernet/mscc/ocelot.c
 130 +++ b/drivers/net/ethernet/mscc/ocelot.c
 131 @@ -2294,6 +2294,18 @@ void ocelot_set_cpu_port(struct ocelot *
 132                          enum ocelot_tag_prefix injection,
 133                          enum ocelot_tag_prefix extraction)
 134  {
 135 +       int port;
 136 +
 137 +       for (port = 0; port < ocelot->num_phys_ports; port++) {
 138 +               /* Disable old CPU port and enable new one */
 139 +               ocelot_rmw_rix(ocelot, 0, BIT(ocelot->cpu),
 140 +                              ANA_PGID_PGID, PGID_SRC + port);
 141 +               if (port == cpu)
 142 +                       continue;
 143 +               ocelot_rmw_rix(ocelot, BIT(cpu), BIT(cpu),
 144 +                              ANA_PGID_PGID, PGID_SRC + port);
 145 +       }
 146 +
 147         /* Configure and enable the CPU port. */
 148         ocelot_write_rix(ocelot, 0, ANA_PGID_PGID, cpu);
 149         ocelot_write_rix(ocelot, BIT(cpu), ANA_PGID_PGID, PGID_CPU);