1. 23 Jun, 2020 10 commits
    • Igor Russkikh's avatar
      net: atlantic: A2: half duplex support · 071a0204
      Igor Russkikh authored
      This patch adds support for 10M/100M/1G half duplex rates, which are
      supported by A2 in additional to full duplex rates supported by A1.
      Signed-off-by: default avatarIgor Russkikh <irusskikh@marvell.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      071a0204
    • Stephen Rothwell's avatar
    • Gaurav Singh's avatar
      tcindex_change: Remove redundant null check · c5efcf17
      Gaurav Singh authored
      arg cannot be NULL since its already being dereferenced
      before. Remove the redundant NULL check.
      Signed-off-by: default avatarGaurav Singh <gaurav1086@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c5efcf17
    • Russell King's avatar
      net: mtk_eth_soc: use resolved link config in mac_link_up() · 75674e31
      Russell King authored
      Convert the mtk_eth_soc driver to use the finalised link parameters in
      mac_link_up() rather than the parameters in mac_config().
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      75674e31
    • David S. Miller's avatar
      Merge branch 'Multicast-improvement-in-Ocelot-and-Felix-drivers' · 864cefee
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Multicast improvement in Ocelot and Felix drivers
      
      This series makes some basic multicast forwarding functionality work for
      Felix DSA and for Ocelot switchdev. IGMP/MLD snooping in Felix is still
      missing, and there are other improvements to be made in the general area
      of multicast address filtering towards the CPU, but let's get these
      hardware-specific fixes out of the way first.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      864cefee
    • Vladimir Oltean's avatar
      net: mscc: ocelot: support IPv4, IPv6 and plain Ethernet mdb entries · 9403c158
      Vladimir Oltean authored
      The current procedure for installing a multicast address is hardcoded
      for IPv4. But, in the ocelot hardware, there are 3 different procedures
      for IPv4, IPv6 and for regular L2 multicast.
      
      For IPv6 (33-33-xx-xx-xx-xx), it's the same as for IPv4
      (01-00-5e-xx-xx-xx), except that the destination port mask is stuffed
      into first 2 bytes of the MAC address except into first 3 bytes.
      
      For plain Ethernet multicast, there's no port-in-address stuffing going
      on, instead the DEST_IDX (pointer to PGID) is used there, just as for
      unicast. So we have to use one of the nonreserved multicast PGIDs that
      the hardware has allocated for this purpose.
      
      This patch classifies the type of multicast address based on its first
      bytes, then redirects to one of the 3 different hardware procedures.
      
      Note that this gives us a really better way of redirecting PTP frames
      sent at 01-1b-19-00-00-00 to the CPU. Previously, Yangbo Lu tried to add
      a trapping rule for PTP EtherType but got a lot of pushback:
      
      https://patchwork.ozlabs.org/project/netdev/patch/20190813025214.18601-5-yangbo.lu@nxp.com/
      
      But right now, that isn't needed at all. The application stack (ptp4l)
      does this for the PTP multicast addresses it's interested in (which are
      configurable, and include 01-1b-19-00-00-00):
      
      	memset(&mreq, 0, sizeof(mreq));
      	mreq.mr_ifindex = index;
      	mreq.mr_type = PACKET_MR_MULTICAST;
      	mreq.mr_alen = MAC_LEN;
      	memcpy(mreq.mr_address, addr1, MAC_LEN);
      
      	err1 = setsockopt(fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &mreq,
      			  sizeof(mreq));
      
      Into the kernel, this translates into a dev_mc_add on the switch network
      interfaces, and our drivers know that it means they should translate it
      into a host MDB address (make the CPU port be the destination).
      Previously, this was broken because all mdb addresses were treated as
      IPv4 (which 01-1b-19-00-00-00 obviously is not).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9403c158
    • Vladimir Oltean's avatar
      net: mscc: ocelot: introduce macros for iterating over PGIDs · 96b029b0
      Vladimir Oltean authored
      The current iterators are impossible to understand at first glance
      without switching back and forth between the definitions and their
      actual use in the for loops.
      
      So introduce some convenience names to help readability.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      96b029b0
    • Vladimir Oltean's avatar
      net: dsa: felix: call port mdb operations from ocelot · 209edf95
      Vladimir Oltean authored
      This adds the mdb hooks in felix and exports the mdb functions from
      ocelot.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      209edf95
    • Vladimir Oltean's avatar
      net: mscc: ocelot: make the NPI port a proper target for FDB and MDB · 471beb11
      Vladimir Oltean authored
      When used in DSA mode (as seen in Felix), the DEST_IDX in the MAC table
      should point to the PGID for the CPU port (PGID_CPU) and not for the
      Ethernet port where the CPU queues are redirected to (also known as Node
      Processor Interface - NPI).
      
      Because for Felix this distinction shouldn't really matter (from DSA
      perspective, the NPI port _is_ the CPU port), make the ocelot library
      act upon the CPU port when NPI mode is enabled. This has no effect for
      the mscc_ocelot driver for VSC7514, because that does not use NPI (and
      ocelot->npi is -1).
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      471beb11
    • Vladimir Oltean's avatar
      net: mscc: ocelot: fix encoding destination ports into multicast IPv4 address · 0897ecf7
      Vladimir Oltean authored
      The ocelot hardware designers have made some hacks to support multicast
      IPv4 and IPv6 addresses. Normally, the MAC table matches on MAC
      addresses and the destination ports are selected through the DEST_IDX
      field of the respective MAC table entry. The DEST_IDX points to a Port
      Group ID (PGID) which contains the bit mask of ports that frames should
      be forwarded to. But there aren't a lot of PGIDs (only 80 or so) and
      there are clearly many more IP multicast addresses than that, so it
      doesn't scale to use this PGID mechanism, so something else was done.
      Since the first portion of the MAC address is known, the hack they did
      was to use a single PGID for _flooding_ unknown IPv4 multicast
      (PGID_MCIPV4 == 62), but for known IP multicast, embed the destination
      ports into the first 3 bytes of the MAC address recorded in the MAC
      table.
      
      The VSC7514 datasheet explains it like this:
      
          3.9.1.5 IPv4 Multicast Entries
      
          MAC table entries with the ENTRY_TYPE = 2 settings are interpreted
          as IPv4 multicast entries.
          IPv4 multicasts entries match IPv4 frames, which are classified to
          the specified VID, and which have DMAC = 0x01005Exxxxxx, where
          xxxxxx is the lower 24 bits of the MAC address in the entry.
          Instead of a lookup in the destination mask table (PGID), the
          destination set is programmed as part of the entry MAC address. This
          is shown in the following table.
      
          Table 78: IPv4 Multicast Destination Mask
      
              Destination Ports            Record Bit Field
              ---------------------------------------------
              Ports 10-0                   MAC[34-24]
      
          Example: All IPv4 multicast frames in VLAN 12 with MAC 01005E112233 are
          to be forwarded to ports 3, 8, and 9. This is done by inserting the
          following entry in the MAC table entry:
          VALID = 1
          VID = 12
          MAC = 0x000308112233
          ENTRY_TYPE = 2
          DEST_IDX = 0
      
      But this procedure is not at all what's going on in the driver. In fact,
      the code that embeds the ports into the MAC address looks like it hasn't
      actually been tested. This patch applies the procedure described in the
      datasheet.
      
      Since there are many other fixes to be made around multicast forwarding
      until it works properly, there is no real reason for this patch to be
      backported to stable trees, or considered a real fix of something that
      should have worked.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0897ecf7
  2. 22 Jun, 2020 30 commits