1. 11 Jun, 2021 16 commits
    • Julian Wiedmann's avatar
      s390/qeth: also use TX NAPI for non-IQD devices · 7a4b92e8
      Julian Wiedmann authored
      Set scan_threshold = 0 to opt out from the qdio layer's internal tasklet
      & timer mechanism for TX completions, and replace it with the TX NAPI
      infrastructure that qeth already uses for IQD devices. This avoids the
      fragile logic in qdio_check_output_queue(), enables tighter integration
      and gives us more tuning options via ethtool in the future.
      
      For now we continue to apply the same policy as the qdio layer:
      scan for completions if 32 TX buffers are in use, or after 1 sec.
      A re-scan is done after 10 sec, but only if no TX interrupt is pending.
      
      With scan_threshold = 0 we no longer get TX completion scans from
      within qdio_get_next_buffers(). So trigger these manually in qeth_poll()
      and in the RX path switch to the equivalent qdio_inspect_queue().
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7a4b92e8
    • Julian Wiedmann's avatar
      s390/qeth: count TX completion interrupts · e872d0c1
      Julian Wiedmann authored
      While the qdio layer already tracks the number of HW interrupts for a
      device, there's value in understanding how many of them have been
      raised due to our TX completion logic.
      Signed-off-by: default avatarJulian Wiedmann <jwi@linux.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e872d0c1
    • David S. Miller's avatar
      Merge branch 'sja1110-dsa-tagging' · e5b0a1b7
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      DSA tagging driver for NXP SJA1110
      
      This series adds support for tagging data and control packets on the new
      NXP SJA1110 switch (supported by the sja1105 driver). Up to this point
      it used the sja1105 driver, which allowed it to send data packets, but
      not PDUs as those required by STP and PTP.
      
      To accommodate this new tagger which has both a header and a trailer, we
      need to refactor the entire DSA tagging scheme, to replace the "overhead"
      concept with separate "needed_headroom" and "needed_tailroom" concepts,
      so that SJA1110 can declare its need for both.
      
      There is also some consolidation work for the receive path of tag_8021q
      and its callers (sja1105 and ocelot-8021q).
      
      Changes in v3:
      Rebase in front of the "Port the SJA1105 DSA driver to XPCS" series
      which seems to have stalled for now.
      
      Changes in v2:
      Export the dsa_8021q_rcv and sja1110_process_meta_tstamp symbols to
      avoid build errors as modules.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e5b0a1b7
    • Vladimir Oltean's avatar
      net: dsa: sja1105: implement TX timestamping for SJA1110 · 566b18c8
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      566b18c8
    • Vladimir Oltean's avatar
      net: dsa: sja1105: add the RX timestamping procedure for SJA1110 · 30b73242
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      30b73242
    • Vladimir Oltean's avatar
      net: dsa: add support for the SJA1110 native tagging protocol · 4913b8eb
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4913b8eb
    • Vladimir Oltean's avatar
      net: dsa: sja1105: make SJA1105_SKB_CB fit a full timestamp · 617ef8d9
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      617ef8d9
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: refactor RX VLAN parsing into a dedicated function · 233697b3
      Vladimir Oltean authored
      The added value of this function is that it can deal with both the case
      where the VLAN header is in the skb head, as well as in the offload field.
      This is something I was not able to do using other functions in the
      network stack.
      
      Since both ocelot-8021q and sja1105 need to do the same stuff, let's
      make it a common service provided by tag_8021q.
      
      This is done as refactoring for the new SJA1110 tagger, which partly
      uses tag_8021q as well (just like SJA1105), and will be the third caller.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      233697b3
    • Vladimir Oltean's avatar
      net: dsa: tag_8021q: remove shim declarations · ab6a303c
      Vladimir Oltean authored
      All users of tag_8021q select it in Kconfig, so shim functions are not
      needed because it is not possible for it to be disabled and its callers
      enabled.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab6a303c
    • Vladimir Oltean's avatar
      net: dsa: tag_sja1105: stop resetting network and transport headers · baa3ad08
      Vladimir Oltean authored
      This makes no sense and is not needed, it is probably a debugging
      leftover.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      baa3ad08
    • Vladimir Oltean's avatar
      net: dsa: generalize overhead for taggers that use both headers and trailers · 4e500251
      Vladimir Oltean authored
      Some really really weird switches just couldn't decide whether to use a
      normal or a tail tagger, so they just did both.
      
      This creates problems for DSA, because we only have the concept of an
      'overhead' which can be applied to the headroom or to the tailroom of
      the skb (like for example during the central TX reallocation procedure),
      depending on the value of bool tail_tag, but not to both.
      
      We need to generalize DSA to cater for these odd switches by
      transforming the 'overhead / tail_tag' pair into 'needed_headroom /
      needed_tailroom'.
      
      The DSA master's MTU is increased to account for both.
      
      The flow dissector code is modified such that it only calls the DSA
      adjustment callback if the tagger has a non-zero header length.
      
      Taggers are trivially modified to declare either needed_headroom or
      needed_tailroom, based on the tail_tag value that they currently
      declare.
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e500251
    • Vladimir Oltean's avatar
      net: dsa: sja1105: allow RX timestamps to be taken on all ports for SJA1110 · 6c0de59b
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6c0de59b
    • Vladimir Oltean's avatar
      net: dsa: sja1105: enable the TTEthernet engine on SJA1110 · 29305260
      Vladimir Oltean authored
      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: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      29305260
    • David S. Miller's avatar
      Merge branch 'hns3-ptp' · f244e256
      David S. Miller authored
      Guangbin Huang says:
      
      ====================
      net: hns3: add support for PTP
      
      This series adds PTP support for the HNS3 ethernet driver.
      
      change log:
      V1 -> V2:
      1. use spinlock to prevent concurrency
      2. add the handling when ptp_clock_register() returns NULL
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f244e256
    • Huazhong Tan's avatar
      net: hns3: add debugfs support for ptp info · b34c157f
      Huazhong Tan authored
      Add a debugfs interface for dumping ptp information, which
      is helpful for debugging.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b34c157f
    • Huazhong Tan's avatar
      net: hns3: add support for PTP · 0bf5eb78
      Huazhong Tan authored
      Adds PTP support for HNS3 ethernet driver.
      Signed-off-by: default avatarHuazhong Tan <tanhuazhong@huawei.com>
      Signed-off-by: default avatarYufeng Mo <moyufeng@huawei.com>
      Signed-off-by: default avatarGuangbin Huang <huangguangbin2@huawei.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0bf5eb78
  2. 10 Jun, 2021 24 commits