1. 06 May, 2019 40 commits
    • Heiner Kallweit's avatar
      r8169: move EEE LED config to rtl8168_config_eee_mac · f452825d
      Heiner Kallweit authored
      Move adjusting the EEE LED frequency to rtl8168_config_eee_mac.
      Exclude RTL8411 (version 38) like in the existing code.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f452825d
    • Heiner Kallweit's avatar
      r8169: simplify rtl_writephy_batch and rtl_ephy_init · 1791ad50
      Heiner Kallweit authored
      Make both functions macros to allow omitting the ARRAY_SIZE(x) argument.
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      1791ad50
    • David S. Miller's avatar
      Merge branch 'Traffic-support-for-SJA1105-DSA-driver' · 0e5ef5a2
      David S. Miller authored
      Vladimir Oltean says:
      
      ====================
      Traffic support for SJA1105 DSA driver
      
      This patch set is a continuation of the "NXP SJA1105 DSA driver" v3
      series, which was split in multiple pieces for easier review.
      
      Supporting a fully-featured (traffic-capable) driver for this switch
      requires some rework in DSA and also leaves behind a more generic
      infrastructure for other dumb switches that rely on 802.1Q pseudo-switch
      tagging for port separation. Among the DSA changes required are:
      
      * Generic xmit and rcv functions for pushing/popping 802.1Q tags on
        skb's. These are modeled as a tagging protocol of its own but which
        must be customized by drivers to fit their own hardware possibilities.
      
      * Permitting the .setup callback to invoke switchdev operations that
        will loop back into the driver through the switchdev notifier chain.
      
      The SJA1105 driver then proceeds to extend this 8021q switch tagging
      protocol while adding its own (tag_sja1105). This is done because
      the driver actually implements a "dual tagger":
      
      * For normal traffic it uses 802.1Q tags
      
      * For management (multicast DMAC) frames the switch has native support
        for recognizing and annotating these with source port and switch id
        information.
      
      Because this is a "dual tagger", decoding of management frames should
      still function when regular traffic can't (under a bridge with VLAN
      filtering).
      There was intervention in the DSA receive hotpath, where a new
      filtering function called from eth_type_trans() is needed. This is
      useful in the general sense for switches that might actually have some
      limited means of source port decoding, such as only for management
      traffic, but not for everything.
      In order for the 802.1Q tagging protocol (which cannot be enabled under
      all conditions, unlike the management traffic decoding) to not be an
      all-or-nothing choice, the filtering function matches everything that
      can be decoded, and everything else is left to pass to the master
      netdevice.
      
      Lastly, DSA core support was added for drivers to request skb deferral.
      SJA1105 needs this for SPI intervention during transmission of link-local
      traffic. This is not done from within the tagger.
      
      Some patches were carried over unchanged from the previous patchset
      (01/09). Others were slightly reworked while adapting to the recent
      changes in "Make DSA tag drivers kernel modules" (02/09).
      
      The introduction of some structures (DSA_SKB_CB, dp->priv) may seem a
      little premature at this point and the new structures under-utilized.
      The reason is that traffic support has been rewritten with PTP
      timestamping in mind, and then I removed the timestamping code from the
      current submission (1. it is a different topic, 2. it does not work very
      well yet). On demand I can provide the timestamping patchset as a RFC
      though.
      
      "NXP SJA1105 DSA driver" v3 patchset can be found at:
      https://lkml.org/lkml/2019/4/12/978
      
      v1 patchset can be found at:
      https://lkml.org/lkml/2019/5/3/877
      
      Changes in v2:
      
      * Made the deferred xmit workqueue also be drained on the netdev suspend
        callback, not just on ndo_stop.
      
      * Added clarification about how other netdevices may be bridged with the
        switch ports.
      
      v2 patchset can be found at:
      https://www.spinics.net/lists/netdev/msg568818.html
      
      Changes in v3:
      
      * Exported the dsa_port_vid_add and dsa_port_vid_del symbols to fix an
        error reported by the kbuild test robot
      
      * Fixed the following checkpatch warnings in 05/10:
        Macro argument reuse 'skb' - possible side-effects?
        Macro argument reuse 'clone' - possible side-effects?
      
      * Added a commit description to the documentation patch (10/10)
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0e5ef5a2
    • Vladimir Oltean's avatar
      Documentation: net: dsa: sja1105: Add info about supported traffic modes · 0a58d471
      Vladimir Oltean authored
      This adds a table which illustrates what combinations of management /
      regular traffic work depending on the state the switch ports are in.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      0a58d471
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add support for Spanning Tree Protocol · 640f763f
      Vladimir Oltean authored
      While not explicitly documented as supported in UM10944, compliance with
      the STP states can be obtained by manipulating 3 settings at the
      (per-port) MAC config level: dynamic learning, inhibiting reception of
      regular traffic, and inhibiting transmission of regular traffic.
      
      In all these modes, transmission and reception of special BPDU frames
      from the stack is still enabled (not inhibited by the MAC-level
      settings).
      
      On ingress, BPDUs are classified by the MAC filter as link-local
      (01-80-C2-00-00-00) and forwarded to the CPU port.  This mechanism works
      under all conditions (even without the custom 802.1Q tagging) because
      the switch hardware inserts the source port and switch ID into bytes 4
      and 5 of the MAC-filtered frames. Then the DSA .rcv handler needs to put
      back zeroes into the MAC address after decoding the source port
      information.
      
      On egress, BPDUs are transmitted using management routes from the xmit
      worker thread. Again this does not require switch tagging, as the switch
      port is programmed through SPI to hold a temporary (single-fire) route
      for a frame with the programmed destination MAC (01-80-C2-00-00-00).
      
      STP is activated using the following commands and was tested by
      connecting two front-panel ports together and noticing that switching
      loops were prevented (one port remains in the blocking state):
      
      $ ip link add name br0 type bridge stp_state 1 && ip link set br0 up
      $ for eth in $(ls /sys/devices/platform/soc/2100000.spi/spi_master/spi0/spi0.1/net/);
        do ip link set ${eth} master br0 && ip link set ${eth} up; done
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      640f763f
    • Vladimir Oltean's avatar
      net: dsa: sja1105: Add support for traffic through standalone ports · 227d07a0
      Vladimir Oltean authored
      In order to support this, we are creating a make-shift switch tag out of
      a VLAN trunk configured on the CPU port. Termination of normal traffic
      on switch ports only works when not under a vlan_filtering bridge.
      Termination of management (PTP, BPDU) traffic works under all
      circumstances because it uses a different tagging mechanism
      (incl_srcpt). We are making use of the generic CONFIG_NET_DSA_TAG_8021Q
      code and leveraging it from our own CONFIG_NET_DSA_TAG_SJA1105.
      
      There are two types of traffic: regular and link-local.
      
      The link-local traffic received on the CPU port is trapped from the
      switch's regular forwarding decisions because it matched one of the two
      DMAC filters for management traffic.
      
      On transmission, the switch requires special massaging for these
      link-local frames. Due to a weird implementation of the switching IP, by
      default it drops link-local frames that originate on the CPU port.
      It needs to be told where to forward them to, through an SPI command
      ("management route") that is valid for only a single frame.
      So when we're sending link-local traffic, we are using the
      dsa_defer_xmit mechanism.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      227d07a0
    • Vladimir Oltean's avatar
      net: dsa: Add a private structure pointer to dsa_port · c362beb0
      Vladimir Oltean authored
      This is supposed to share information between the driver and the tagger,
      or used by the tagger to keep some state. Its use is optional.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c362beb0
    • Vladimir Oltean's avatar
      net: dsa: Add support for deferred xmit · 97a69a0d
      Vladimir Oltean authored
      Some hardware needs to take work to get convinced to receive frames on
      the CPU port (such as the sja1105 which takes temporary L2 forwarding
      rules over SPI that last for a single frame). Such work needs a
      sleepable context, and because the regular .ndo_start_xmit is atomic,
      this cannot be done in the tagger. So introduce a generic DSA mechanism
      that sets up a transmit skb queue and a workqueue for deferred
      transmission.
      
      The new driver callback (.port_deferred_xmit) is in dsa_switch and not
      in the tagger because the operations that require sleeping typically
      also involve interacting with the hardware, and not simply skb
      manipulations. Therefore having it there simplifies the structure a bit
      and makes it unnecessary to export functions from the driver to the
      tagger.
      
      The driver is responsible of calling dsa_enqueue_skb which transfers it
      to the master netdevice. This is so that it has a chance of performing
      some more work afterwards, such as cleanup or TX timestamping.
      
      To tell DSA that skb xmit deferral is required, I have thought about
      changing the return type of the tagger .xmit from struct sk_buff * into
      a enum dsa_tx_t that could potentially encode a DSA_XMIT_DEFER value.
      
      But the trailer tagger is reallocating every skb on xmit and therefore
      making a valid use of the pointer return value. So instead of reworking
      the API in complicated ways, right now a boolean property in the newly
      introduced DSA_SKB_CB is set.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      97a69a0d
    • Vladimir Oltean's avatar
      net: dsa: Keep private info in the skb->cb · b68b0dd0
      Vladimir Oltean authored
      Map a DSA structure over the 48-byte control block that will hold
      skb info on transmit and receive. This is only for use within the DSA
      processing layer (e.g. communicating between DSA core and tagger) and
      not for passing info around with other layers such as the master net
      device.
      
      Also add a DSA_SKB_CB_PRIV() macro which retrieves a pointer to the
      space up to 48 bytes that the DSA structure does not use. This space can
      be used for drivers to add their own private info.
      
      One use is for the PTP timestamping code path. When cloning a skb,
      annotate the original with a pointer to the clone, which the driver can
      then find easily and place the timestamp to. This avoids the need of a
      separate queue to hold clones and a way to match an original to a cloned
      skb.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b68b0dd0
    • Vladimir Oltean's avatar
      net: dsa: Allow drivers to filter packets they can decode source port from · cc1939e4
      Vladimir Oltean authored
      Frames get processed by DSA and redirected to switch port net devices
      based on the ETH_P_XDSA multiplexed packet_type handler found by the
      network stack when calling eth_type_trans().
      
      The running assumption is that once the DSA .rcv function is called, DSA
      is always able to decode the switch tag in order to change the skb->dev
      from its master.
      
      However there are tagging protocols (such as the new DSA_TAG_PROTO_SJA1105,
      user of DSA_TAG_PROTO_8021Q) where this assumption is not completely
      true, since switch tagging piggybacks on the absence of a vlan_filtering
      bridge. Moreover, management traffic (BPDU, PTP) for this switch doesn't
      rely on switch tagging, but on a different mechanism. So it would make
      sense to at least be able to terminate that.
      
      Having DSA receive traffic it can't decode would put it in an impossible
      situation: the eth_type_trans() function would invoke the DSA .rcv(),
      which could not change skb->dev, then eth_type_trans() would be invoked
      again, which again would call the DSA .rcv, and the packet would never
      be able to exit the DSA filter and would spiral in a loop until the
      whole system dies.
      
      This happens because eth_type_trans() doesn't actually look at the skb
      (so as to identify a potential tag) when it deems it as being
      ETH_P_XDSA. It just checks whether skb->dev has a DSA private pointer
      installed (therefore it's a DSA master) and that there exists a .rcv
      callback (everybody except DSA_TAG_PROTO_NONE has that). This is
      understandable as there are many switch tags out there, and exhaustively
      checking for all of them is far from ideal.
      
      The solution lies in introducing a filtering function for each tagging
      protocol. In the absence of a filtering function, all traffic is passed
      to the .rcv DSA callback. The tagging protocol should see the filtering
      function as a pre-validation that it can decode the incoming skb. The
      traffic that doesn't match the filter will bypass the DSA .rcv callback
      and be left on the master netdevice, which wasn't previously possible.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cc1939e4
    • Vladimir Oltean's avatar
      net: dsa: Optional VLAN-based port separation for switches without tagging · f9bbe447
      Vladimir Oltean authored
      This patch provides generic DSA code for using VLAN (802.1Q) tags for
      the same purpose as a dedicated switch tag for injection/extraction.
      It is based on the discussions and interest that has been so far
      expressed in https://www.spinics.net/lists/netdev/msg556125.html.
      
      Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q
      does not offer a complete solution for drivers (nor can it). Instead, it
      provides generic code that driver can opt into calling:
      - dsa_8021q_xmit: Inserts a VLAN header with the specified contents.
        Can be called from another tagging protocol's xmit function.
        Currently the LAN9303 driver is inserting headers that are simply
        802.1Q with custom fields, so this is an opportunity for code reuse.
      - dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb.
        Removing the VLAN header is left as a decision for the caller to make.
      - dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID
        and a Tx VID, for proper untagged traffic identification on ingress
        and steering on egress. Also sets up the VLAN trunk on the upstream
        (CPU or DSA) port. Drivers are intentionally left to call this
        function explicitly, depending on the context and hardware support.
        The expected switch behavior and VLAN semantics should not be violated
        under any conditions. That is, after calling
        dsa_port_setup_8021q_tagging, the hardware should still pass all
        ingress traffic, be it tagged or untagged.
      
      For uniformity with the other tagging protocols, a module for the
      dsa_8021q_netdev_ops structure is registered, but the typical usage is
      to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q,
      and calls the API from tag_8021q.h. Null function definitions are also
      provided so that a "depends on" is not forced in the Kconfig.
      
      This tagging protocol only works when switch ports are standalone, or
      when they are added to a VLAN-unaware bridge. It will probably remain
      this way for the reasons below.
      
      When added to a bridge that has vlan_filtering 1, the bridge core will
      install its own VLANs and reset the pvids through switchdev. For the
      bridge core, switchdev is a write-only pipe. All VLAN-related state is
      kept in the bridge core and nothing is read from DSA/switchdev or from
      the driver. So the bridge core will break this port separation because
      it will install the vlan_default_pvid into all switchdev ports.
      
      Even if we could teach the bridge driver about switchdev preference of a
      certain vlan_default_pvid (task difficult in itself since the current
      setting is per-bridge but we would need it per-port), there would still
      exist many other challenges.
      
      Firstly, in the DSA rcv callback, a driver would have to perform an
      iterative reverse lookup to find the correct switch port. That is
      because the port is a bridge slave, so its Rx VID (port PVID) is subject
      to user configuration. How would we ensure that the user doesn't reset
      the pvid to a different value (which would make an O(1) translation
      impossible), or to a non-unique value within this DSA switch tree (which
      would make any translation impossible)?
      
      Finally, not all switch ports are equal in DSA, and that makes it
      difficult for the bridge to be completely aware of this anyway.
      The CPU port needs to transmit tagged packets (VLAN trunk) in order for
      the DSA rcv code to be able to decode source information.
      But the bridge code has absolutely no idea which switch port is the CPU
      port, if nothing else then just because there is no netdevice registered
      by DSA for the CPU port.
      Also DSA does not currently allow the user to specify that they want the
      CPU port to do VLAN trunking anyway. VLANs are added to the CPU port
      using the same flags as they were added on the user port.
      
      So the VLANs installed by dsa_port_setup_8021q_tagging per driver
      request should remain private from the bridge's and user's perspective,
      and should not alter the VLAN semantics observed by the user.
      
      In the current implementation a VLAN range ending at 4095 (VLAN_N_VID)
      is reserved for this purpose. Each port receives a unique Rx VLAN and a
      unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they
      serve different purposes: on Rx the switch must process traffic as
      untagged and process it with a port-based VLAN, but with care not to
      hinder bridging. On the other hand, the Tx VLAN is where the
      reachability restrictions are imposed, since by tagging frames in the
      xmit callback we are telling the switch onto which port to steer the
      frame.
      
      Some general guidance on how this support might be employed for
      real-life hardware (some comments made by Florian Fainelli):
      
      - If the hardware supports VLAN tag stacking, it should somehow back
        up its private VLAN settings when the bridge tries to override them.
        Then the driver could re-apply them as outer tags. Dedicating an outer
        tag per bridge device would allow identical inner tag VID numbers to
        co-exist, yet preserve broadcast domain isolation.
      
      - If the switch cannot handle VLAN tag stacking, it should disable this
        port separation when added as slave to a vlan_filtering bridge, in
        that case having reduced functionality.
      
      - Drivers for old switches that don't support the entire VLAN_N_VID
        range will need to rework the current range selection mechanism.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f9bbe447
    • Vladimir Oltean's avatar
      net: dsa: Export symbols for dsa_port_vid_{add, del} · 146c1bed
      Vladimir Oltean authored
      This is needed so that the newly introduced tag_8021q may access these
      core DSA functions when built as a module.
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      146c1bed
    • Vladimir Oltean's avatar
      net: dsa: Call driver's setup callback after setting up its switchdev notifier · b2243b36
      Vladimir Oltean authored
      This allows the driver to perform some manipulations of its own during
      setup, using generic switchdev calls. Having the notifiers registered at
      setup time is important because otherwise any switchdev transaction
      emitted during this time would be ignored (dispatched to an empty call
      chain).
      
      One current usage scenario is for the driver to request DSA to set up
      802.1Q based switch tagging for its ports.
      
      There is no danger for the driver setup code to start racing now with
      switchdev events emitted from the network stack (such as bridge core)
      even if the notifier is registered earlier. This is because the network
      stack needs a net_device as a vehicle to perform switchdev operations,
      and the slave net_devices are registered later than the core driver
      setup anyway (ds->ops->setup in dsa_switch_setup vs dsa_port_setup).
      
      Luckily DSA doesn't need a net_device to carry out switchdev callbacks,
      and therefore drivers shouldn't assume either that net_devices are
      available at the time their switchdev callbacks get invoked.
      Signed-off-by: default avatarVladimir Oltean <olteanv@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Reviewed-by: Vivien Didelot <vivien.didelot@gmail.com>-
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b2243b36
    • Vivien Didelot's avatar
      net: dsa: mv88e6xxx: refine SMI support · e7ba0fad
      Vivien Didelot authored
      The Marvell SOHO switches have several ways to access the internal
      registers. One of them being the System Management Interface (SMI),
      using the MDC and MDIO pins, with direct and indirect variants.
      
      In preparation for adding support for other register accesses, move
      the SMI code into its own files. At the same time, refine the code
      to make it clear that the indirect variant is implemented using the
      direct variant accessing only two registers for command and data.
      Signed-off-by: default avatarVivien Didelot <vivien.didelot@gmail.com>
      Reviewed-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      e7ba0fad
    • David S. Miller's avatar
      Merge branch 'net-act_police-offload-support' · 7e6a95d3
      David S. Miller authored
      Jakub Kicinski says:
      
      ===================
      net: act_police offload support
      
      this set starts by converting cls_matchall to the new flow offload
      infrastructure. It so happens that all drivers implementing cls_matchall
      offload today also offload cls_flower, so its a little easier for
      them to handle the actions in unified flow_rule format, even though
      in cls_matchall there is no flow to speak of. If a driver ever appears
      which would prefer the old, direct access to TC exts, we can add the
      pointer in the offload structure back and support both.
      
      Next the act_police is added to actions supported by flow offload API.
      
      NFP support for act_police offload is added as the final step.  The flower
      firmware is configured to perform TX rate limiting in a way which matches
      act_police's behaviour.  It does not use DMA.IN back pressure, and
      instead	drops packets after they had been already DMAed into the NIC.
      IOW it uses our standard traffic policing implementation, future patches
      will extend it to other ports and traffic directions.
      ===================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e6a95d3
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload stats request and reply · 5fb5c395
      Pieter Jansen van Vuuren authored
      Add stats request function that sends a stats request message to hw for
      a specific police-filter. Process stats reply from hw and update the
      stored qos structure.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fb5c395
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload install and remove functionality. · 49cbef13
      Pieter Jansen van Vuuren authored
      Add install and remove offload functionality for qos offloads. We
      first check that a police filter can be implemented by the VF rate
      limiting feature in hw, then we install the filter via the qos
      infrastructure. Finally we implement the mechanism for removing
      these types of filters.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      49cbef13
    • Pieter Jansen van Vuuren's avatar
      nfp: flower: add qos offload framework · b66d035e
      Pieter Jansen van Vuuren authored
      Introduce matchall filter offload infrastructure that is needed to
      offload qos features like policing. Subsequent patches will make
      use of police-filters for ingress rate limiting.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b66d035e
    • Pieter Jansen van Vuuren's avatar
      net/sched: add block pointer to tc_cls_common_offload structure · 88c44a52
      Pieter Jansen van Vuuren authored
      Some actions like the police action are stateful and could share state
      between devices. This is incompatible with offloading to multiple devices
      and drivers might want to test for shared blocks when offloading.
      Store a pointer to the tcf_block structure in the tc_cls_common_offload
      structure to allow drivers to determine when offloads apply to a shared
      block.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      88c44a52
    • Pieter Jansen van Vuuren's avatar
      net/sched: allow stats updates from offloaded police actions · 12f02b6b
      Pieter Jansen van Vuuren authored
      Implement the stats_update callback for the police action that
      will be used by drivers for hardware offload.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      12f02b6b
    • Pieter Jansen van Vuuren's avatar
      net/sched: extend matchall offload for hardware statistics · b7fe4ab8
      Pieter Jansen van Vuuren authored
      Introduce a new command for matchall classifiers that allows hardware
      to update statistics.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      b7fe4ab8
    • Pieter Jansen van Vuuren's avatar
      net/sched: add police action to the hardware intermediate representation · 8c8cfc6e
      Pieter Jansen van Vuuren authored
      Add police action to the hardware intermediate representation which
      would subsequently allow it to be used by drivers for offload.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8c8cfc6e
    • Pieter Jansen van Vuuren's avatar
      net/sched: move police action structures to header · fa762da9
      Pieter Jansen van Vuuren authored
      Move tcf_police_params, tcf_police and tc_police_compat structures to a
      header. Making them usable to other code for example drivers that would
      offload police actions to hardware.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      fa762da9
    • Pieter Jansen van Vuuren's avatar
      net/sched: remove unused functions for matchall offload · dfcb19f0
      Pieter Jansen van Vuuren authored
      Cleanup unused functions and variables after porting to the newer
      intermediate representation.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfcb19f0
    • Pieter Jansen van Vuuren's avatar
      net/dsa: use intermediate representation for matchall offload · 9681e8b3
      Pieter Jansen van Vuuren authored
      Updates dsa hardware switch handling infrastructure to use the newer
      intermediate representation for flow actions in matchall offloads.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      9681e8b3
    • Pieter Jansen van Vuuren's avatar
      mlxsw: use intermediate representation for matchall offload · ab79af32
      Pieter Jansen van Vuuren authored
      Updates the Mellanox spectrum driver to use the newer intermediate
      representation for flow actions in matchall offloads.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ab79af32
    • Pieter Jansen van Vuuren's avatar
      net/sched: use the hardware intermediate representation for matchall · f00cbf19
      Pieter Jansen van Vuuren authored
      Extends matchall offload to make use of the hardware intermediate
      representation. More specifically, this patch moves the native TC
      actions in cls_matchall offload to the newer flow_action
      representation. This ultimately allows us to avoid a direct
      dependency on native TC actions for matchall.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f00cbf19
    • Pieter Jansen van Vuuren's avatar
      net/sched: add sample action to the hardware intermediate representation · a7a7be60
      Pieter Jansen van Vuuren authored
      Add sample action to the hardware intermediate representation model which
      would subsequently allow it to be used by drivers for offload.
      Signed-off-by: default avatarPieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
      Reviewed-by: default avatarJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: default avatarJiri Pirko <jiri@mellanox.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a7a7be60
    • David S. Miller's avatar
      Merge branch 'of_net-Add-NVMEM-support-to-of_get_mac_address' · c8f8207c
      David S. Miller authored
      Petr Štetiar says:
      
      ====================
      of_net: Add NVMEM support to of_get_mac_address
      
      this patch series is a continuation of my previous attempt[1], where I've
      tried to wire MTD layer into of_get_mac_address, so it would be possible to
      load MAC addresses from various NVMEMs as EEPROMs etc.
      
      Predecessor of this patch which used directly MTD layer has originated in
      OpenWrt some time ago and supports already about 497 use cases in 357
      device tree files.
      
      During the review process of my 1st attempt I was told, that I shouldn't be
      using MTD directly, but that I should rather use new NVMEM subsystem and
      during the review process of v2 I was told, that I should handle
      EPROBE_DEFFER error as well, during the review process of v3 I was told,
      that returning pointer/NULL/ERR_PTR is considered as wrong API design, so
      this v4 patch series tries to accommodate all this previous remarks.
      
      First patch is wiring NVMEM support directly into of_get_mac_address as
      it's obvious, that adding support for NVMEM into every other driver would
      mean adding a lot of repetitive code. This patch allows us to configure MAC
      addresses in various devices like ethernet and wireless adapters directly
      from of_get_mac_address, which is used by quite a lot of drivers in the
      tree already.
      
      Second patch is simply updating documentation with NVMEM bits, and cleaning
      up all current binding documentation referencing any of the MAC address
      related properties.
      
      Third and fourth patches are simply removing duplicate NVMEM code which is
      no longer needed as the first patch has wired NVMEM support directly into
      of_get_mac_address.
      
      Patches 5-10 are converting all current users of of_get_mac_address to the
      new ERR_PTR encoded error value, as of_get_mac_address could now return
      valid pointer, NULL and ERR_PTR.
      
      Just for a better picture, this patch series and one simple patch[2] on top
      of it, allows me to configure 8Devices Carambola2 board's MAC addresses
      with following DTS (simplified):
      
       &spi {
       	flash@0 {
       		partitions {
      			art: partition@ff0000 {
      				label = "art";
      				reg = <0xff0000 0x010000>;
      				read-only;
      
      				nvmem-cells {
      					compatible = "nvmem-cells";
      					#address-cells = <1>;
      					#size-cells = <1>;
      
      					eth0_addr: eth-mac-addr@0 {
      						reg = <0x0 0x6>;
      					};
      
      					eth1_addr: eth-mac-addr@6 {
      						reg = <0x6 0x6>;
      					};
      
      					wmac_addr: wifi-mac-addr@1002 {
      						reg = <0x1002 0x6>;
      					};
      				};
      			};
      		};
      	};
       };
      
       &eth0 {
      	nvmem-cells = <&eth0_addr>;
      	nvmem-cell-names = "mac-address";
       };
      
       &eth1 {
      	nvmem-cells = <&eth1_addr>;
      	nvmem-cell-names = "mac-address";
       };
      
       &wmac {
      	nvmem-cells = <&wmac_addr>;
      	nvmem-cell-names = "mac-address";
       };
      
      1. https://patchwork.ozlabs.org/patch/1086628/
      2. https://patchwork.ozlabs.org/patch/890738/
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c8f8207c
    • Petr Štetiar's avatar
      powerpc: tsi108: support of_get_mac_address new ERR_PTR error · ea168cdf
      Petr Štetiar authored
      There was NVMEM support added to of_get_mac_address, so it could now return
      ERR_PTR encoded error values, so we need to adjust all current users of
      of_get_mac_address to this new fact.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ea168cdf
    • Petr Štetiar's avatar
      ARM: Kirkwood: support of_get_mac_address new ERR_PTR error · c41593a0
      Petr Štetiar authored
      There was NVMEM support added to of_get_mac_address, so it could now return
      ERR_PTR encoded error values, so we need to adjust all current users of
      of_get_mac_address to this new fact.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c41593a0
    • Petr Štetiar's avatar
      staging: octeon-ethernet: support of_get_mac_address new ERR_PTR error · 284eb160
      Petr Štetiar authored
      There was NVMEM support added to of_get_mac_address, so it could now return
      ERR_PTR encoded error values, so we need to adjust all current users of
      of_get_mac_address to this new fact.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      284eb160
    • Petr Štetiar's avatar
      net: wireless: support of_get_mac_address new ERR_PTR error · d31a36b5
      Petr Štetiar authored
      There was NVMEM support added to of_get_mac_address, so it could now return
      ERR_PTR encoded error values, so we need to adjust all current users of
      of_get_mac_address to this new fact.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d31a36b5
    • Petr Štetiar's avatar
      net: usb: support of_get_mac_address new ERR_PTR error · adfb3cb2
      Petr Štetiar authored
      There was NVMEM support added to of_get_mac_address, so it could now return
      ERR_PTR encoded error values, so we need to adjust all current users of
      of_get_mac_address to this new fact.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      adfb3cb2
    • Petr Štetiar's avatar
      net: davinci: support of_get_mac_address new ERR_PTR error · f7af25a6
      Petr Štetiar authored
      There was NVMEM support added directly to of_get_mac_address, and it uses
      nvmem_get_mac_address under the hood, so we can remove it. As
      of_get_mac_address can now return ERR_PTR encoded error values, adjust to
      that as well.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f7af25a6
    • Petr Štetiar's avatar
      net: macb: support of_get_mac_address new ERR_PTR error · 541ddc66
      Petr Štetiar authored
      There was NVMEM support added directly to of_get_mac_address, and it uses
      nvmem_get_mac_address under the hood, so we can remove it. As
      of_get_mac_address can now return ERR_PTR encoded error values, adjust to
      that as well.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      541ddc66
    • Petr Štetiar's avatar
      dt-bindings: doc: reflect new NVMEM of_get_mac_address behaviour · 687e3d55
      Petr Štetiar authored
      As of_get_mac_address now supports NVMEM under the hood, we need to update
      the bindings documentation with the new nvmem-cell* properties, which would
      mean copy&pasting a lot of redundant information to every binding
      documentation currently referencing some of the MAC address properties.
      
      So I've just removed all the references to the optional MAC address
      properties and replaced them with the small note referencing
      net/ethernet.txt file.
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      687e3d55
    • Petr Štetiar's avatar
      of_net: add NVMEM support to of_get_mac_address · d01f449c
      Petr Štetiar authored
      Many embedded devices have information such as MAC addresses stored
      inside NVMEMs like EEPROMs and so on. Currently there are only two
      drivers in the tree which benefit from NVMEM bindings.
      
      Adding support for NVMEM into every other driver would mean adding a lot
      of repetitive code. This patch allows us to configure MAC addresses in
      various devices like ethernet and wireless adapters directly from
      of_get_mac_address, which is already used by almost every driver in the
      tree.
      
      Predecessor of this patch which used directly MTD layer has originated
      in OpenWrt some time ago and supports already about 497 use cases in 357
      device tree files.
      
      Cc: Alban Bedel <albeu@free.fr>
      Signed-off-by: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohn Crispin <john@phrozen.org>
      Signed-off-by: default avatarPetr Štetiar <ynezz@true.cz>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d01f449c
    • David S. Miller's avatar
      Merge branch 'bnxt_en-Driver-updates' · 8ef5cc4f
      David S. Miller authored
      Michael Chan says:
      
      ====================
      bnxt_en: Driver updates.
      
      This patch series adds some extended statistics available with the new
      firmware interface, package version from firmware, aRFS support on
      57500 chips, new PCI IDs, and some miscellaneous fixes and improvements.
      ====================
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      8ef5cc4f
    • Michael Chan's avatar
      bnxt_en: Add device IDs 0x1806 and 0x1752 for 57500 devices. · 51fec80d
      Michael Chan authored
      0x1806 and 0x1752 are VF variant and PF variant of the 57500 chip
      family.
      Signed-off-by: default avatarMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51fec80d