1. 02 7月, 2021 5 次提交
  2. 29 6月, 2021 1 次提交
    • V
      net: dsa: sja1105: fix dynamic access to L2 Address Lookup table for SJA1110 · 74e7feff
      Vladimir Oltean 提交于
      The SJA1105P/Q/R/S and SJA1110 may have the same layout for the command
      to read/write/search for L2 Address Lookup entries, but as explained in
      the comments at the beginning of the sja1105_dynamic_config.c file, the
      command portion of the buffer is at the end, and we need to obtain a
      pointer to it by adding the length of the entry to the buffer.
      
      Alas, the length of an L2 Address Lookup entry is larger in SJA1110 than
      it is for SJA1105P/Q/R/S, so we need to create a common helper to access
      the command buffer, and this receives as argument the length of the
      entry buffer.
      
      Fixes: 3e77e59b ("net: dsa: sja1105: add support for the SJA1110 switch family")
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      74e7feff
  3. 25 6月, 2021 2 次提交
  4. 23 6月, 2021 1 次提交
  5. 22 6月, 2021 1 次提交
    • E
      net: dsa: mv88e6xxx: Fix adding vlan 0 · b8b79c41
      Eldar Gasanov 提交于
      8021q module adds vlan 0 to all interfaces when it starts.
      When 8021q module is loaded it isn't possible to create bond
      with mv88e6xxx interfaces, bonding module dipslay error
      "Couldn't add bond vlan ids", because it tries to add vlan 0
      to slave interfaces.
      
      There is unexpected behavior in the switch. When a PVID
      is assigned to a port the switch changes VID to PVID
      in ingress frames with VID 0 on the port. Expected
      that the switch doesn't assign PVID to tagged frames
      with VID 0. But there isn't a way to change this behavior
      in the switch.
      
      Fixes: 57e661aa ("net: dsa: mv88e6xxx: Link aggregation support")
      Signed-off-by: NEldar Gasanov <eldargasanov2@gmail.com>
      Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8b79c41
  6. 19 6月, 2021 3 次提交
    • V
      net: dsa: sja1105: completely error out in sja1105_static_config_reload if something fails · 61c77533
      Vladimir Oltean 提交于
      If reloading the static config fails for whatever reason, for example if
      sja1105_static_config_check_valid() fails, then we "goto out_unlock_ptp"
      but we print anyway that "Reset switch and programmed static config.",
      which is confusing because we didn't. We also do a bunch of other stuff
      like reprogram the XPCS and reload the credit-based shapers, as if a
      switch reset took place, which didn't.
      
      So just unlock the PTP lock and goto out, skipping all of that.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      61c77533
    • V
      net: dsa: sja1105: allow the TTEthernet configuration in the static config for SJA1110 · 1303e7f9
      Vladimir Oltean 提交于
      Currently sja1105_static_config_check_valid() is coded up to detect
      whether TTEthernet is supported based on device ID, and this check was
      not updated to cover SJA1110.
      
      However, it is desirable to have as few checks for the device ID as
      possible, so the driver core is more generic. So what we can do is look
      at the static config table operations implemented by that specific
      switch family (populated by sja1105_static_config_init) whether the
      schedule table has a non-zero maximum entry count (meaning that it is
      supported) or not.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1303e7f9
    • V
      net: dsa: sja1105: properly power down the microcontroller clock for SJA1110 · cb5a82d2
      Vladimir Oltean 提交于
      It turns out that powering down the BASE_TIMER_CLK does not turn off the
      microcontroller, just its timers, including the one for the watchdog.
      So the embedded microcontroller is still running, and potentially still
      doing things.
      
      To prevent unwanted interference, we should power down the BASE_MCSS_CLK
      as well (MCSS = microcontroller subsystem).
      
      The trouble is that currently we turn off the BASE_TIMER_CLK for SJA1110
      from the .clocking_setup() method, mostly because this is a Clock
      Generation Unit (CGU) setting which was traditionally configured in that
      method for SJA1105. But in SJA1105, the CGU was used for bringing up the
      port clocks at the proper speeds, and in SJA1110 it's not (but rather
      for initial configuration), so it's best that we rebrand the
      sja1110_clocking_setup() method into what it really is - an implementation
      of the .disable_microcontroller() method.
      
      Since disabling the microcontroller only needs to be done once, at probe
      time, we can choose the best place to do that as being in sja1105_setup(),
      before we upload the static config to the device. This guarantees that
      the static config being used by the switch afterwards is really ours.
      
      Note that the procedure to upload a static config necessarily resets the
      switch. This already did not reset the microcontroller, only the switch
      core, so since the .disable_microcontroller() method is guaranteed to be
      called by that point, if it's disabled, it remains disabled. Add a
      comment to make that clear.
      
      With the code movement for SJA1110 from .clocking_setup() to
      .disable_microcontroller(), both methods are optional and are guarded by
      "if" conditions.
      
      Tested by enabling in the device tree the rev-mii switch port 0 that
      goes towards the microcontroller, and flashing a firmware that would
      have networking. Without this patch, the microcontroller can be pinged,
      with this patch it cannot.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      cb5a82d2
  7. 17 6月, 2021 1 次提交
  8. 16 6月, 2021 1 次提交
  9. 15 6月, 2021 6 次提交
  10. 12 6月, 2021 10 次提交
    • V
      net: dsa: sja1105: plug in support for 2500base-x · 56b63466
      Vladimir Oltean 提交于
      The MAC treats 2500base-x same as SGMII (yay for that) except that it
      must be set to a different speed.
      
      Extend all places that check for SGMII to also check for 2500base-x.
      
      Also add the missing 2500base-x compatibility matrix entry for SJA1110D.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      56b63466
    • V
      net: dsa: sja1105: SGMII and 2500base-x on the SJA1110 are 'special' · ece578bc
      Vladimir Oltean 提交于
      For the xMII Mode Parameters Table to be properly configured for SGMII
      mode on SJA1110, we need to set the "special" bit, since SGMII is
      officially bitwise coded as 0b0011 in SJA1105 (decimal 3, equal to
      XMII_MODE_SGMII), and as 0b1011 in SJA1110 (decimal 11).
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ece578bc
    • V
      net: dsa: sja1105: register the PCS MDIO bus for SJA1110 · 27871359
      Vladimir Oltean 提交于
      On the SJA1110, the PCS of each SERDES-capable port is accessed through
      a different memory window which is 0x100 bytes in size, denoted by
      "pcs_base".
      
      In each PCS register access window, the XPCS MMDs are accessed in an
      indirect way: in pages/banks of up to 0x100 addresses each. Changing the
      page/bank is done by writing to a special register at the end of the
      access window.
      
      The MDIO register map accessed indirectly through the indirect banked
      method described above is similar to what SJA1105 has: upper 5 bits are
      the MMD, lower 16 bits are the MDIO address within that MMD.
      
      Since the PHY ID reported by the XPCS inside SJA1110 is also all zeroes
      (like SJA1105), we need to trap those reads and return a fake PHY ID so
      that the xpcs driver can apply some specific fixups for our integration.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      27871359
    • V
      net: dsa: sja1105: migrate to xpcs for SGMII · 3ad1d171
      Vladimir Oltean 提交于
      There is a desire to use the generic driver for the Synopsys XPCS
      located in drivers/net/pcs, and to achieve that, the sja1105 driver must
      expose an MDIO bus for the SGMII PCS, because the XPCS probes as an
      mdio_device.
      
      In preparation of the SJA1110 which in fact has a different access
      procedure for the SJA1105, we register this PCS MDIO bus once in the
      common code, but we implement function pointers for the read and write
      methods. In this patch there is a single implementation for them.
      
      There is exactly one MDIO bus for the PCS, this will contain all PCSes
      at MDIO addresses equal to the port number.
      
      We delete a bunch of hardware support code because the xpcs driver
      already does what we need.
      
      We need to hack up the MDIO reads for the PHY ID, since our XPCS
      instantiation returns zeroes and there are some specific fixups which
      need to be applied by the xpcs driver.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ad1d171
    • V
      net: dsa: sja1105: implement TX timestamping for SJA1110 · 566b18c8
      Vladimir Oltean 提交于
      The TX timestamping procedure for SJA1105 is a bit unconventional
      because the transmit procedure itself is unconventional.
      
      Control packets (and therefore PTP as well) are transmitted to a
      specific port in SJA1105 using "management routes" which must be written
      over SPI to the switch. These are one-shot rules that match by
      destination MAC address on traffic coming from the CPU port, and select
      the precise destination port for that packet. So to transmit a packet
      from NET_TX softirq context, we actually need to defer to a process
      context so that we can perform that SPI write before we send the packet.
      The DSA master dev_queue_xmit() runs in process context, and we poll
      until the switch confirms it took the TX timestamp, then we annotate the
      skb clone with that TX timestamp. This is why the sja1105 driver does
      not need an skb queue for TX timestamping.
      
      But the SJA1110 is a bit (not much!) more conventional, and you can
      request 2-step TX timestamping through the DSA header, as well as give
      the switch a cookie (timestamp ID) which it will give back to you when
      it has the timestamp. So now we do need a queue for keeping the skb
      clones until their TX timestamps become available.
      
      The interesting part is that the metadata frames from SJA1105 haven't
      disappeared completely. On SJA1105 they were used as follow-ups which
      contained RX timestamps, but on SJA1110 they are actually TX completion
      packets, which contain a variable (up to 32) array of timestamps.
      Why an array? Because:
      - not only is the TX timestamp on the egress port being communicated,
        but also the RX timestamp on the CPU port. Nice, but we don't care
        about that, so we ignore it.
      - because a packet could be multicast to multiple egress ports, each
        port takes its own timestamp, and the TX completion packet contains
        the individual timestamps on each port.
      
      This is unconventional because switches typically have a timestamping
      FIFO and raise an interrupt, but this one doesn't. So the tagger needs
      to detect and parse meta frames, and call into the main switch driver,
      which pairs the timestamps with the skbs in the TX timestamping queue
      which are waiting for one.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      566b18c8
    • V
      net: dsa: sja1105: add the RX timestamping procedure for SJA1110 · 30b73242
      Vladimir Oltean 提交于
      This is really easy, since the full RX timestamp is in the DSA trailer
      and the tagger code transfers it to SJA1105_SKB_CB(skb)->tstamp, we just
      need to move it to the skb shared info region. This is as opposed to
      SJA1105, where the RX timestamp was received in a meta frame (so there
      needed to be a state machine to pair the 2 packets) and the timestamp
      was partial (so the packet, once matched with its timestamp, needed to
      be added to an RX timestamping queue where the PTP aux worker would
      reconstruct that timestamp).
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      30b73242
    • V
      net: dsa: add support for the SJA1110 native tagging protocol · 4913b8eb
      Vladimir Oltean 提交于
      The SJA1110 has improved a few things compared to SJA1105:
      
      - To send a control packet from the host port with SJA1105, one needed
        to program a one-shot "management route" over SPI. This is no longer
        true with SJA1110, you can actually send "in-band control extensions"
        in the packets sent by DSA, these are in fact DSA tags which contain
        the destination port and switch ID.
      
      - When receiving a control packet from the switch with SJA1105, the
        source port and switch ID were written in bytes 3 and 4 of the
        destination MAC address of the frame (which was a very poor shot at a
        DSA header). If the control packet also had an RX timestamp, that
        timestamp was sent in an actual follow-up packet, so there were
        reordering concerns on multi-core/multi-queue DSA masters, where the
        metadata frame with the RX timestamp might get processed before the
        actual packet to which that timestamp belonged (there is no way to
        pair a packet to its timestamp other than the order in which they were
        received). On SJA1110, this is no longer true, control packets have
        the source port, switch ID and timestamp all in the DSA tags.
      
      - Timestamps from the switch were partial: to get a 64-bit timestamp as
        required by PTP stacks, one would need to take the partial 24-bit or
        32-bit timestamp from the packet, then read the current PTP time very
        quickly, and then patch in the high bits of the current PTP time into
        the captured partial timestamp, to reconstruct what the full 64-bit
        timestamp must have been. That is awful because packet processing is
        done in NAPI context, but reading the current PTP time is done over
        SPI and therefore needs sleepable context.
      
      But it also aggravated a few things:
      
      - Not only is there a DSA header in SJA1110, but there is a DSA trailer
        in fact, too. So DSA needs to be extended to support taggers which
        have both a header and a trailer. Very unconventional - my understanding
        is that the trailer exists because the timestamps couldn't be prepared
        in time for putting them in the header area.
      
      - Like SJA1105, not all packets sent to the CPU have the DSA tag added
        to them, only control packets do:
      
        * the ones which match the destination MAC filters/traps in
          MAC_FLTRES1 and MAC_FLTRES0
        * the ones which match FDB entries which have TRAP or TAKETS bits set
      
        So we could in theory hack something up to request the switch to take
        timestamps for all packets that reach the CPU, and those would be
        DSA-tagged and contain the source port / switch ID by virtue of the
        fact that there needs to be a timestamp trailer provided. BUT:
      
      - The SJA1110 does not parse its own DSA tags in a way that is useful
        for routing in cross-chip topologies, a la Marvell. And the sja1105
        driver already supports cross-chip bridging from the SJA1105 days.
        It does that by automatically setting up the DSA links as VLAN trunks
        which contain all the necessary tag_8021q RX VLANs that must be
        communicated between the switches that span the same bridge. So when
        using tag_8021q on sja1105, it is possible to have 2 switches with
        ports sw0p0, sw0p1, sw1p0, sw1p1, and 2 VLAN-unaware bridges br0 and
        br1, and br0 can take sw0p0 and sw1p0, and br1 can take sw0p1 and
        sw1p1, and forwarding will happen according to the expected rules of
        the Linux bridge.
        We like that, and we don't want that to go away, so as a matter of
        fact, the SJA1110 tagger still needs to support tag_8021q.
      
      So the sja1110 tagger is a hybrid between tag_8021q for data packets,
      and the native hardware support for control packets.
      
      On RX, packets have a 13-byte trailer if they contain an RX timestamp.
      That trailer is padded in such a way that its byte 8 (the start of the
      "residence time" field - not parsed by Linux because we don't care) is
      aligned on a 16 byte boundary. So the padding has a variable length
      between 0 and 15 bytes. The DSA header contains the offset of the
      beginning of the padding relative to the beginning of the frame (and the
      end of the padding is obviously the end of the packet minus 13 bytes,
      the length of the trailer). So we discard it.
      
      Packets which don't have a trailer contain the source port and switch ID
      information in the header (they are "trap-to-host" packets). Packets
      which have a trailer contain the source port and switch ID in the trailer.
      
      On TX, the destination port mask and switch ID is always in the trailer,
      so we always need to say in the header that a trailer is present.
      
      The header needs a custom EtherType and this was chosen as 0xdadc, after
      0xdada which is for Marvell and 0xdadb which is for VLANs in
      VLAN-unaware mode on SJA1105 (and SJA1110 in fact too).
      
      Because we use tag_8021q in concert with the native tagging protocol,
      control packets will have 2 DSA tags.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4913b8eb
    • V
      net: dsa: sja1105: make SJA1105_SKB_CB fit a full timestamp · 617ef8d9
      Vladimir Oltean 提交于
      In SJA1105, RX timestamps for packets sent to the CPU are transmitted in
      separate follow-up packets (metadata frames). These contain partial
      timestamps (24 or 32 bits) which are kept in SJA1105_SKB_CB(skb)->meta_tstamp.
      
      Thankfully, SJA1110 improved that, and the RX timestamps are now
      transmitted in-band with the actual packet, in the timestamp trailer.
      The RX timestamps are now full-width 64 bits.
      
      Because we process the RX DSA tags in the rcv() method in the tagger,
      but we would like to preserve the DSA code structure in that we populate
      the skb timestamp in the port_rxtstamp() call which only happens later,
      the implication is that we must somehow pass the 64-bit timestamp from
      the rcv() method all the way to port_rxtstamp(). We can use the skb->cb
      for that.
      
      Rename the meta_tstamp from struct sja1105_skb_cb from "meta_tstamp" to
      "tstamp", and increase its size to 64 bits.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      617ef8d9
    • V
      net: dsa: sja1105: allow RX timestamps to be taken on all ports for SJA1110 · 6c0de59b
      Vladimir Oltean 提交于
      On SJA1105, there is support for a cascade port which is presumably
      connected to a downstream SJA1105 switch. The upstream one does not take
      PTP timestamps for packets received on this port, presumably because the
      downstream switch already did (and for PTP, it only makes sense for the
      leaf nodes in a DSA switch tree to do that).
      
      I haven't been able to validate that feature in a fully assembled setup,
      so I am disabling the feature by setting the cascade port to an unused
      port value (ds->num_ports).
      
      In SJA1110, multiple cascade ports are supported, and CASC_PORT became
      a bit mask from a port number. So when CASC_PORT is set to ds->num_ports
      (which is 11 on SJA1110), it is actually set to 0b1011, so ports 3, 1
      and 0 are configured as cascade ports and we cannot take RX timestamps
      on them.
      
      So we need to introduce a check for SJA1110 and set things differently
      (to zero there), so that the cascading feature is properly disabled and
      RX timestamps can be taken on all ports.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6c0de59b
    • V
      net: dsa: sja1105: enable the TTEthernet engine on SJA1110 · 29305260
      Vladimir Oltean 提交于
      As opposed to SJA1105 where there are parts with TTEthernet and parts
      without, in SJA1110 all parts support it, but it must be enabled in the
      static config. So enable it unconditionally. We use it for the tc-taprio
      and tc-gate offload.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      29305260
  11. 10 6月, 2021 4 次提交
  12. 09 6月, 2021 4 次提交
    • V
      net: dsa: felix: set TX flow control according to the phylink_mac_link_up resolution · de274be3
      Vladimir Oltean 提交于
      Instead of relying on the static initialization done by ocelot_init_port()
      which enables flow control unconditionally, set SYS_PAUSE_CFG_PAUSE_ENA
      according to the parameters negotiated by the PHY.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de274be3
    • V
      net: dsa: sja1105: register the MDIO buses for 100base-T1 and 100base-TX · 5a8f0974
      Vladimir Oltean 提交于
      The SJA1110 contains two types of integrated PHYs: one 100base-TX PHY
      and multiple 100base-T1 PHYs.
      
      The access procedure for the 100base-T1 PHYs is also different than it
      is for the 100base-TX one. So we register 2 MDIO buses, one for the
      base-TX and the other for the base-T1. Each bus has an OF node which is
      a child of the "mdio" subnode of the switch, and they are recognized by
      compatible string.
      
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: devicetree@vger.kernel.org
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a8f0974
    • V
      net: dsa: sja1105: make sure the retagging port is enabled for SJA1110 · ceec8bc0
      Vladimir Oltean 提交于
      The SJA1110 has an extra configuration in the General Parameters Table
      through which the user can select the buffer reservation config.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      ceec8bc0
    • V
      net: dsa: sja1105: add support for the SJA1110 switch family · 3e77e59b
      Vladimir Oltean 提交于
      The SJA1110 is basically an SJA1105 with more ports, some integrated
      PHYs (100base-T1 and 100base-TX) and an embedded microcontroller which
      can be disabled, and the switch core can be controlled by a host running
      Linux, over SPI.
      
      This patch contains:
      - the static and dynamic config packing functions, for the tables that
        are common with SJA1105
      - one more static config tables which is "unique" to the SJA1110
        (actually it is a rehash of stuff that was placed somewhere else in
        SJA1105): the PCP Remapping Table
      - a reset and clock configuration procedure for the SJA1110 switch.
        This resets just the switch subsystem, and gates off the clock which
        powers on the embedded microcontroller.
      - an RGMII delay configuration procedure for SJA1110, which is very
        similar to SJA1105, but different enough for us to be unable to reuse
        it (this is a pattern that repeats itself)
      - some adaptations to dynamic config table entries which are no longer
        programmed in the same way. For example, to delete a VLAN, you used to
        write an entry through the dynamic reconfiguration interface with the
        desired VLAN ID, and with the VALIDENT bit set to false. Now, the VLAN
        table entries contain a TYPE_ENTRY field, which must be set to zero
        (in a backwards-incompatible way) in order for the entry to be deleted,
        or to some other entry for the VLAN to match "inner tagged" or "outer
        tagged" packets.
      - a similar thing for the static config: the xMII Mode Parameters Table
        encoding for SGMII and MII (the latter just when attached to a
        100base-TX PHY) just isn't what it used to be in SJA1105. They are
        identical, except there is an extra "special" bit which needs to be
        set. Set it.
      Signed-off-by: NVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e77e59b
  13. 08 6月, 2021 1 次提交