The xgbe driver reuses MII_ADDR_C45 for its own purpose. The values
derived with it are never passed to phylib or a linux MDIO bus driver.
In order that MII_ADDR_C45 can be removed, add an XGBE specific
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The xgbe MDIO bus driver can perform both C22 and C45 transfers, when
using its MDIO bus hardware. The SFP I2C mdio bus driver only supports
C22. Create separate functions for each and register the C45 versions
using the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The hns MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

When performing a C45 bus transaction, make use of the c45 variants of
the bus read/write helpers. The ability to pass a special register
value is being removed to clean up the mdio bus driver API.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The ixgbe MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The macb MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The nixge MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

The sxgdb MDIO bus driver can perform both C22 and C45 transfers.
Create separate functions for each and register the C45 versions using
the new API calls where appropriate.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

mt7530 does support C45, but its uses a mix of registering its MDIO
bus and providing its private MDIO bus to the DSA core, too. This makes
the change a bit more complex.
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Signed-off-by: NMichael Walle <michael@walle.cc>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Convert various mult-bit fields to be defined using GENMASK/FIELD_PREP.
Simplify the code with the ternary operator.
Signed-off-by: NMengyuan Lou <mengyuanlou@net-swift.com>
Reviewed-by: NSimon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/r/20230116103839.84087-1-mengyuanlou@net-swift.comSigned-off-by: NJakub Kicinski <kuba@kernel.org>

Wolfram Sang says:

====================
Immutable branch adding fwnode API to the I2C core

I2C changes requested by Russell King.
This allows him to rework SFP code further.

* tag 'i2c-fwnode-api-2023017' of https://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  i2c: add fwnode APIs
====================

Link: https://lore.kernel.org/r/Y8ZhI4g0wsvpjokd@ninjato/Signed-off-by: NJakub Kicinski <kuba@kernel.org>

Merge tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap

Mark Brown says:

====================
regmap: Rework regmap_mdio_c45_{read|write} for new C45 API.

This reworks the regmap MDIO handling of C45 addresses in
preparation for some forthcoming updates to the networking code.

* tag 'regmap-mdio-c45-rework' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
  regmap: Rework regmap_mdio_c45_{read|write} for new C45 API.
====================

Link: https://lore.kernel.org/r/Y8VjkgcWHjR9TzNw@sirena.org.ukSigned-off-by: NJakub Kicinski <kuba@kernel.org>

The recent refactoring to split C22 and C45 introduced two unneeded
semiconons which the kernel test bot reported. Remove them.
Reported-by: Nkernel test robot <lkp@intel.com>
Fixes: 93641ecb ("net: mdio: cavium: Separate C22 and C45 transactions")
Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
Reviewed-by: NMichael Walle <michael@walle.cc>
Link: https://lore.kernel.org/r/20230115164203.510615-1-andrew@lunn.chSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

__inet_hash_connect() has a fast path taken if sk_head(&tb->owners) is
equal to the sk parameter.
sk_head() returns the hlist_entry() with respect to the sk_node field.
However entries in the tb->owners list are inserted with respect to the
sk_bind_node field with sk_add_bind_node().
Thus the check would never pass and the fast path never execute.

This fast path has never been executed or tested as this bug seems
to be present since commit 1da177e4 ("Linux-2.6.12-rc2"), thus
remove it to reduce code complexity.
Signed-off-by: NPietro Borrello <borrello@diag.uniroma1.it>
Reviewed-by: NKuniyuki Iwashima <kuniyu@amazon.com>
Reviewed-by: NEric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20230112-inet_hash_connect_bind_head-v3-1-b591fd212b93@diag.uniroma1.itSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Lorenzo Bianconi says:

====================
net: ethernet: mtk_wed: introduce reset support

Introduce proper reset integration between ethernet and wlan drivers in order
to schedule wlan driver reset when ethernet/wed driver is resetting.
Introduce mtk_hw_reset_monitor work in order to detect possible DMA hangs.
====================

Link: https://lore.kernel.org/r/cover.1673715298.git.lorenzo@kernel.orgSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Introduce reset and reset_complete wlan callback to schedule WLAN driver
reset when ethernet/wed driver is resetting.
Tested-by: NDaniel Golle <daniel@makrotopia.org>
Co-developed-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Introduce mtk_hw_check_dma_hang routine to monitor possible dma hangs.
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Tested-by: NDaniel Golle <daniel@makrotopia.org>
Co-developed-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Avoid to power-down the ethernet chip during hw reset and align reset
procedure to vendor sdk.
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Tested-by: NDaniel Golle <daniel@makrotopia.org>
Co-developed-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Introduce mtk_hw_warm_reset utility routine. This is a preliminary patch
to align reset procedure to vendor sdk and avoid to power down the chip
during hw reset.
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Tested-by: NDaniel Golle <daniel@makrotopia.org>
Co-developed-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

This is a preliminary patch to add Wireless Ethernet Dispatcher reset
support.
Reviewed-by: NLeon Romanovsky <leonro@nvidia.com>
Tested-by: NDaniel Golle <daniel@makrotopia.org>
Co-developed-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NSujuan Chen <sujuan.chen@mediatek.com>
Signed-off-by: NLorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

Jesper Dangaard Brouer says:

====================
net: use kmem_cache_free_bulk in kfree_skb_list

The kfree_skb_list function walks SKB (via skb->next) and frees them
individually to the SLUB/SLAB allocator (kmem_cache). It is more
efficient to bulk free them via the kmem_cache_free_bulk API.

Netstack NAPI fastpath already uses kmem_cache bulk alloc and free
APIs for SKBs.

The kfree_skb_list call got an interesting optimization in commit
520ac30f ("net_sched: drop packets after root qdisc lock is
released") that can create a list of SKBs "to_free" e.g. when qdisc
enqueue fails or deliberately chooses to drop . It isn't a normal data
fastpath, but the situation will likely occur when system/qdisc are
under heavy workloads, thus it makes sense to use a faster API for
freeing the SKBs.

E.g. the (often distro default) qdisc fq_codel will drop batches of
packets from fattest elephant flow, default capped at 64 packets (but
adjustable via tc argument drop_batch).

Performance measurements done in [1]:
 [1] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org
====================

Link: https://lore.kernel.org/r/167361788585.531803.686364041841425360.stgit@firesoulSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

The kfree_skb_list function walks SKB (via skb->next) and frees them
individually to the SLUB/SLAB allocator (kmem_cache). It is more
efficient to bulk free them via the kmem_cache_free_bulk API.

This patches create a stack local array with SKBs to bulk free while
walking the list. Bulk array size is limited to 16 SKBs to trade off
stack usage and efficiency. The SLUB kmem_cache "skbuff_head_cache"
uses objsize 256 bytes usually in an order-1 page 8192 bytes that is
32 objects per slab (can vary on archs and due to SLUB sharing). Thus,
for SLUB the optimal bulk free case is 32 objects belonging to same
slab, but runtime this isn't likely to occur.

The expected gain from using kmem_cache bulk alloc and free API
have been assessed via a microbencmark kernel module[1].

The module 'slab_bulk_test01' results at bulk 16 element:
 kmem-in-loop Per elem: 109 cycles(tsc) 30.532 ns (step:16)
 kmem-bulk    Per elem: 64 cycles(tsc) 17.905 ns (step:16)

More detailed description of benchmarks avail in [2].

[1] https://github.com/netoptimizer/prototype-kernel/tree/master/kernel/mm
[2] https://github.com/xdp-project/xdp-project/blob/master/areas/mem/kfree_skb_list01.org

V2: rename function to kfree_skb_add_bulk.
Reviewed-by: NSaeed Mahameed <saeed@kernel.org>
Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

The SKB drop reason uses __builtin_return_address(0) to give the call
"location" to trace_kfree_skb() tracepoint skb:kfree_skb.

To keep this stable for compilers kfree_skb_reason() is annotated with
__fix_address (noinline __noclone) as fixed in commit c205cc75
("net: skb: prevent the split of kfree_skb_reason() by gcc").

The function kfree_skb_list_reason() invoke kfree_skb_reason(), which
cause the __builtin_return_address(0) "location" to report the
unexpected address of kfree_skb_list_reason.

Example output from 'perf script':
 kpktgend_0  1337 [000]    81.002597: skb:kfree_skb: skbaddr=0xffff888144824700 protocol=2048 location=kfree_skb_list_reason+0x1e reason: QDISC_DROP

Patch creates an __always_inline __kfree_skb_reason() helper call that
is called from both kfree_skb_list() and kfree_skb_list_reason().
Suggestions for solutions that shares code better are welcome.

As preparation for next patch move __kfree_skb() invocation out of
this helper function.
Reviewed-by: NSaeed Mahameed <saeed@kernel.org>
Signed-off-by: NJesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: NPaolo Abeni <pabeni@redhat.com>

This code checks if (attrs[DEVLINK_ATTR_TRAP_POLICER_ID]) twice.  Once
at the start of the function and then a couple lines later.  Delete the
second check since that one must be true.

Because the second condition is always true, it means the:

	policer_item = group_item->policer_item;

assignment is immediately over-written.  Delete that as well.
Signed-off-by: NDan Carpenter <error27@gmail.com>
Reviewed-by: NJiri Pirko <jiri@nvidia.com>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Reviewed-by: NIdo Schimmel <idosch@nvidia.com>
Link: https://lore.kernel.org/r/Y8EJz8oxpMhfiPUb@kiliSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

We will report extack message if there is an error via netlink_ack(). But
if the rule is not to be exclusively executed by the hardware, extack is not
passed along and offloading failures don't get logged.

In commit 81c7288b ("sched: cls: enable verbose logging") Marcelo
made cls could log verbose info for offloading failures, which helps
improving Open vSwitch debuggability when using flower offloading.

It would also be helpful if userspace monitor tools, like "tc monitor",
could log this kind of message, as it doesn't require vswitchd log level
adjusment. Let's add a new tc attributes to report the extack message so
the monitor program could receive the failures. e.g.

  # tc monitor
  added chain dev enp3s0f1np1 parent ffff: chain 0
  added filter dev enp3s0f1np1 ingress protocol all pref 49152 flower chain 0 handle 0x1
    ct_state +trk+new
    not_in_hw
          action order 1: gact action drop
           random type none pass val 0
           index 1 ref 1 bind 1

  Warning: mlx5_core: matching on ct_state +new isn't supported.

In this patch I only report the extack message on add/del operations.
It doesn't look like we need to report the extack message on get/dump
operations.

Note this message not only reporte to multicast groups, it could also
be reported unicast, which may affect the current usersapce tool's behaivor.
Suggested-by: NMarcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: NHangbin Liu <liuhangbin@gmail.com>
Acked-by: NJakub Kicinski <kuba@kernel.org>
Acked-by: NJamal Hadi Salim <jhs@mojatatu.com>
Link: https://lore.kernel.org/r/20230113034353.2766735-1-liuhangbin@gmail.comSigned-off-by: NPaolo Abeni <pabeni@redhat.com>

Add fwnode APIs for finding and getting I2C adapters, which will be
used by the SFP code. These are passed the fwnode corresponding to
the adapter, and return the I2C adapter. It is the responsibility of
the caller to find the appropriate fwnode.

We keep the DT and ACPI interfaces, but where appropriate, recode them
to use the fwnode interfaces internally.
Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NWolfram Sang <wsa@kernel.org>

Colin Foster says

====================
dt-binding preparation for ocelot switches

Ocelot switches have the abilitiy to be used internally via
memory-mapped IO or externally via SPI or PCIe. This brings up issues
for documentation, where the same chip might be accessed internally in a
switchdev manner, or externally in a DSA configuration. This patch set
is perparation to bring DSA functionality to the VSC7512, utilizing as
much as possible with an almost identical VSC7514 chip.

This patch set changed quite a bit from v2, so I'll omit the background
of how those sets came to be. Rob offered a lot of very useful guidance.
My thanks.

At the end of the day, with this patch set, there should be a framework
to document Ocelot switches (and any switch) in scenarios where they can
be controlled internally (ethernet-switch) or externally (dsa-switch).

---

v6 -> v7
  * Add Reviewed / Acked on patch 1
  * Clean up descriptions on Ethernet / DSA switch port bindings

v5 -> v6
  * Rebase so it applies to net-next cleanly.
  * No other changes - during the last submission round I said I'd
    submit v6 with a change to move $dsa-port.yaml to outside the allOf
    list. In retrospect that wasn't the right thing to do, because later
    in the patch series the $dsa-port.yaml is removed outright. So I
    believe the submission in v5 to keep "type: object" was correct.

v4 -> v5
  * Sync DSA maintainers with MAINTAINERS file (new patch 1)
  * Undo move of port description of mediatek,mt7530.yaml (patch 4)
  * Move removal of "^(ethernet-)?switch(@.*)?$" in dsa.yaml from patch 4
    to patch 8
  * Add more consistent capitalization in title lines and better Ethernet
    switch port description. (patch 8)

v3 -> v4
  * Renamed "base" to "ethernet-ports" to avoid confusion with the concept
    of a base class.
  * Squash ("dt-bindings: net: dsa: mediatek,mt7530: fix port description location")
    patch into ("dt-bindings: net: dsa: utilize base definitions for standard dsa
    switches")
  * Corrections to fix confusion about additonalProperties vs unevaluatedProperties.
    See specific patches for details.

v2 -> v3
  * Restructured everything to use a "base" iref for devices that don't
    have additional properties, and simply a "ref" for devices that do.
  * New patches to fix up brcm,sf2, qca8k, and mt7530
  * Fix unevaluatedProperties errors from previous sets (see specific
    patches for more detail)
  * Removed redundant "Device Tree Binding" from titles, where applicable.

v1 -> v2
  * Two MFD patches were brought into the MFD tree, so are dropped
  * Add first patch 1/6 to allow DSA devices to add ports and port
    properties
  * Test qca8k against new dt-bindings and fix warnings. (patch 2/6)
  * Add tags (patch 3/6)
  * Fix vsc7514 refs and properties
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Several bindings for ethernet switches are available for non-dsa switches
by way of ethernet-switch.yaml. Remove these duplicate entries and utilize
the common bindings for the VSC7514.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The dsa-port.yaml binding had several references that can be common to all
ethernet ports, not just dsa-specific ones. Break out the generic bindings
to ethernet-switch-port.yaml they can be used by non-dsa drivers.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The dsa.yaml bindings had references that can apply to non-dsa switches. To
prevent duplication of this information, keep the dsa-specific information
inside dsa.yaml and move the remaining generic information to the newly
created ethernet-switch.yaml.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

dsa.yaml contains a reference to dsa-port.yaml, so a duplicate reference to
the binding isn't necessary. Remove this unnecessary reference.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NArınç ÜNAL <arinc.unal@arinc9.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The dsa.yaml binding contains duplicated bindings for address and size
cells, as well as the reference to dsa-port.yaml. Instead of duplicating
this information, remove the reference to dsa-port.yaml and include the
full reference to dsa.yaml.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Explicitly allow additional properties for both the ethernet-port and
ethernet-ports properties. This specifically will allow the qca8k.yaml
binding to use shared properties.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

DSA switches can fall into one of two categories: switches where all ports
follow standard '(ethernet-)?port' properties, and switches that have
additional properties for the ports.

The scenario where DSA ports are all standardized can be handled by
switches with a reference to the new 'dsa.yaml#/$defs/ethernet-ports'.

The scenario where DSA ports require additional properties can reference
'$dsa.yaml#' directly. This will allow switches to reference these standard
definitions of the DSA switch, but add additional properties under the port
nodes.
Suggested-by: NRob Herring <robh@kernel.org>
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Reviewed-by: NLinus Walleij <linus.walleij@linaro.org>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Acked-by: Alvin Šipraga <alsi@bang-olufsen.dk> # realtek
Acked-by: NArınç ÜNAL <arinc.unal@arinc9.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The children of the switch node don't have a unit address, and therefore
should not need the #address-cells or #size-cells entries. Fix the example
schemas accordingly.
Suggested-by: NVladimir Oltean <olteanv@gmail.com>
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The property use-bcm-hdr was documented as an entry under the ports node
for the bcm_sf2 DSA switch. This property is actually evaluated for each
port. Correct the documentation to match the actual behavior and properly
reference dsa-port.yaml for additional properties of the node.
Suggested-by: NRob Herring <robh@kernel.org>
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Acked-by: NFlorian Fainelli <f.fainelli@gmail.com>
Reviewed-by: NRob Herring <robh@kernel.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The MAINTAINERS file has Andrew Lunn, Florian Fainelli, and Vladimir Oltean
listed as the maintainers for generic dsa bindings. Update dsa.yaml and
dsa-port.yaml accordingly.
Signed-off-by: NColin Foster <colin.foster@in-advantage.com>
Reviewed-by: NVladimir Oltean <olteanv@gmail.com>
Acked-by: NRob Herring <robh@kernel.org>
Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Steen Hegelund says:

====================
net: microchip: Add support for two classes of VCAP rules

This adds support for two classes of VCAP rules:

- Permanent rules (added e.g. for PTP support)
- TC user rules (added by the TC userspace tool)

For this to work the VCAP Loopups must be enabled from boot, so that the
"internal" clients like PTP can add rules that are always active.

When the TC tool add a flower filter the VCAP rule corresponding to this
filter will be disabled (kept in memory) until a TC matchall filter creates
a link from chain 0 to the chain (lookup) where the flower filter was
added.

When the flower filter is enabled it will be written to the appropriate
VCAP lookup and become active in HW.

Likewise the flower filter will be disabled if there is no link from chain
0 to the chain of the filter (lookup), and when that happens the
corresponding VCAP rule will be read from the VCAP instance and stored in
memory until it is deleted or enabled again.

Version History:
================
v4      Removed a leftover 'Fixes' tag from v2.  No functional changes.

v3      Removed the change that allowed rules to always be added in the
        LAN996x even though the lookups are not enabled (Horatiu Vultur).
        This was sent separately to net instead.

        Removed the 'Fixes' tags due to the patch sent to net by Horatiu
        Vultur.

        Added a check for validity of the chain source when enabling a
        lookup.

v2      Adding a missing goto exit in vcap_add_rule (Dan Carpenter).
        Added missing checks for error returns in vcap_enable_rule.

v1      Initial version
====================
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This supports that individual rules are enabled and disabled via chain
information.
This is done by keeping disabled rules in the VCAP list (cached) until they
are enabled, and only at this time are the rules written to the VCAP HW.
Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

This allows a VCAP rule to be in one of 3 states:

- permanently stored in the VCAP HW (for rules that must always be present)
- enabled (stored in HW) when the corresponding lookup has been enabled
- disabled (stored in SW) when the lookup is disabled

This way important VCAP rules can be added even before the user enables the
VCAP lookups using a TC matchall filter.
Signed-off-by: NHoratiu Vultur <horatiu.vultur@microchip.com>
Signed-off-by: NSteen Hegelund <steen.hegelund@microchip.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>