- 29 Nov, 2022 15 commits
-
-
Lorenzo Bianconi authored
Introduce mtk_wed_rx_reset routine in order to reset rx DMA for Wireless Ethernet Dispatcher available on MT7986 SoC. Co-developed-by:
Sujuan Chen <sujuan.chen@mediatek.com> Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Signed-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Lorenzo Bianconi authored
Update mtk_wed_stop routine and rename old mtk_wed_stop() to mtk_wed_deinit(). This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Remove duplicated code. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Lorenzo Bianconi authored
Move MTK_WDMA_RESET_IDX configuration in mtk_wdma_rx_reset routine. Increase poll timeout to 10ms in order to be aligned with vendor sdk. This is a preliminary patch to add Wireless Ethernet Dispatcher reset support. Co-developed-by:
-
Paolo Abeni authored
Miquel Raynal says: ==================== Marvell nvmem mac addresses support Now that we are aligned on how to make information available from static storage media to drivers like Ethernet controller drivers or switch drivers by using nvmem cells and going through the whole nvmem infrastructure, here are two driver updates to reflect these changes. Prior to the driver updates, I propose: * Reverting binding changes which should have never been accepted like that. * A conversion of the (old) Prestera and DFX server bindings (optional, can be dropped if not considered necessary). * A better description of the more recent Prestera PCI switch. Please mind that this series cannot break anything since retrieving the MAC address Prestera driver has never worked upstream, because the (ONIE tlv) driver supposed to export the MAC address has not been accepted in its original form and has been updated to the nvmem-layout infrastructure (bindings have been merged, the code remains to be applied). ==================== Link: https://lore.kernel.org/r/20221124111556.264647-1-miquel.raynal@bootlin.comSigned-off-by:
-
Miquel Raynal authored
The ONIE standard describes the organization of tlv (type-length-value) arrays commonly stored within NVMEM devices on common networking hardware. Several drivers already make use of NVMEM cells for purposes like retrieving a default MAC address provided by the manufacturer. What made ONIE tables unusable so far was the fact that the information where "dynamically" located within the table depending on the manufacturer wishes, while Linux NVMEM support only allowed statically defined NVMEM cells. Fortunately, this limitation was eventually tackled with the introduction of discoverable cells through the use of NVMEM layouts, making it possible to extract and consistently use the content of tables like ONIE's tlv arrays. Parsing this table at runtime in order to get various information is now possible. So, because many Marvell networking switches already follow this standard, let's consider using NVMEM cells as a new valid source of information when looking for a base MAC address, which is one of the primary uses of these new fields. Indeed, manufacturers following the ONIE standard are encouraged to provide a default MAC address there, so let's eventually use it if no other MAC address has been found using the existing methods. Link: https://opencomputeproject.github.io/onie/design-spec/hw_requirements.htmlSigned-off-by:
Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by:
-
Miquel Raynal authored
This driver fist makes an expensive DT lookup to retrieve its DT node (this is a PCI driver) in order to later search for the base-mac-provider property. This property has no reality upstream and this code should not have been accepted like this in the first place. Instead, there is a proper nvmem interface that should be used. Let's avoid these extra lookups and rely on the nvmem internal logic. Signed-off-by:
-
Miquel Raynal authored
Export of_get_mac_addr_nvmem() and rename it to of_get_mac_address_nvmem() in order to fit the convention followed by the existing exported helpers of the same kind. This way, OF compatible drivers using eg. fwnode_get_mac_address() can do a direct call to it instead of calling of_get_mac_address() just for the nvmem step, avoiding to repeat an expensive DT lookup which has already been done once. Eventually, fwnode_get_mac_address() should probably be updated to perform the nvmem lookup directly, but as of today, nvmem cells seem not to be supported by ACPI yet which would defeat this kind of extension. Suggested-by:
Marcin Wojtas <mw@semihalf.com> Signed-off-by:
-
Miquel Raynal authored
Even though the devices have very little in common beside the name and the main "switch" feature, Marvell Prestera switch family is also composed of PCI-only devices which can receive additional static properties, like nvmem cells to point at MAC addresses, for instance. Let's describe them. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Miquel Raynal authored
The currently described switch family is named AlleyCat3, it is a memory mapped switch found on Armada XP boards. Signed-off-by:
-
Miquel Raynal authored
Even though this description is not used anywhere upstream (no matching driver), while on this file I decided I would try a conversion to yaml in order to clarify the prestera family description. I cannot keep the nodename dfx-server@xxxx so I switched to dfx-bus@xxxx which matches simple-bus.yaml. Otherwise I took the example context from the only user of this compatible: armada-xp-98dx3236.dtsi, which is a rather old and not perfect DT. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
Miquel Raynal authored
This reverts commit 40acc052. marvell,prestera.txt is an old file describing the old Alleycat3 standalone switches. The commit mentioned above actually hacked these bindings to add support for a device tree property for a more modern version of the IP connected over PCI, using only the generic compatible in order to retrieve the device node from the prestera driver to read one static property. The problematic property discussed here is "base-mac-provider". The original intent was to point to a nvmem device which could produce the relevant nvmem-cell. This property has never been acked by DT maintainers and fails all the layering that has been brought with the nvmem bindings by pointing at a nvmem producer, bypassing the existing nvmem bindings, rather than a nvmem cell directly. Furthermore, the property cannot even be used upstream because it expected the ONIE tlv driver to produce a specific cell, driver which used nacked bindings and thus was never merged, replaced by a more integrated concept: the nvmem-layout. So let's forget about this temporary addition, safely avoiding the need for any backward compatibility handling. A new (yaml) binding file will be brought with the prestera bindings, and there we will actually include a description of the modern IP over PCI, including the right way to point to a nvmem cell. Cc: Vadym Kochan <vadym.kochan@plvision.eu> Cc: Taras Chornyi <tchornyi@marvell.com> Signed-off-by:
-
Jakub Kicinski authored
==================== bpf-next 2022-11-25 We've added 101 non-merge commits during the last 11 day(s) which contain a total of 109 files changed, 8827 insertions(+), 1129 deletions(-). The main changes are: 1) Support for user defined BPF objects: the use case is to allocate own objects, build own object hierarchies and use the building blocks to build own data structures flexibly, for example, linked lists in BPF, from Kumar Kartikeya Dwivedi. 2) Add bpf_rcu_read_{,un}lock() support for sleepable programs, from Yonghong Song. 3) Add support storing struct task_struct objects as kptrs in maps, from David Vernet. 4) Batch of BPF map documentation improvements, from Maryam Tahhan and Donald Hunter. 5) Improve BPF verifier to propagate nullness information for branches of register to register comparisons, from Eduard Zingerman. 6) Fix cgroup BPF iter infra to hold reference on the start cgroup, from Hou Tao. 7) Fix BPF verifier to not mark fentry/fexit program arguments as trusted given it is not the case for them, from Alexei Starovoitov. 8) Improve BPF verifier's realloc handling to better play along with dynamic runtime analysis tools like KASAN and friends, from Kees Cook. 9) Remove legacy libbpf mode support from bpftool, from Sahid Orentino Ferdjaoui. 10) Rework zero-len skb redirection checks to avoid potentially breaking existing BPF test infra users, from Stanislav Fomichev. 11) Two small refactorings which are independent and have been split out of the XDP queueing RFC series, from Toke Høiland-Jørgensen. 12) Fix a memory leak in LSM cgroup BPF selftest, from Wang Yufen. 13) Documentation on how to run BPF CI without patch submission, from Daniel Müller. Signed-off-by:Jakub Kicinski <kuba@kernel.org> ==================== Link: https://lore.kernel.org/r/20221125012450.441-1-daniel@iogearbox.netSigned-off-by:
-
Vladimir Oltean authored
This reverts commit f72cd76b. This patch is so broken, it hurts. Apparently no one reviewed it and it passed the build testing (because the code was compiled out), but it was obviously never compile-tested, since it produces the following build error, due to an incomplete conversion where an extra argument was left, although the function being called was left: stmmac_main.c: In function ‘stmmac_cmdline_opt’: stmmac_main.c:7586:28: error: too many arguments to function ‘sysfs_streq’ 7586 | } else if (sysfs_streq(opt, "pause:", 6)) { | ^~~~~~~~~~~ In file included from ../include/linux/bitmap.h:11, from ../include/linux/cpumask.h:12, from ../include/linux/smp.h:13, from ../include/linux/lockdep.h:14, from ../include/linux/mutex.h:17, from ../include/linux/notifier.h:14, from ../include/linux/clk.h:14, from ../drivers/net/ethernet/stmicro/stmmac/stmmac_main.c:17: ../include/linux/string.h:185:13: note: declared here 185 | extern bool sysfs_streq(const char *s1, const char *s2); | ^~~~~~~~~~~ What's even worse is that the patch is flat out wrong. The stmmac_cmdline_opt() function does not parse sysfs input, but cmdline input such as "stmmaceth=tc:1,pause:1". The pattern of using strsep() followed by strncmp() for such strings is not unique to stmmac, it can also be found mainly in drivers under drivers/video/fbdev/. With strncmp("tc:", 3), the code matches on the "tc:1" token properly. With sysfs_streq("tc:"), it doesn't. Fixes: f72cd76b ("net: stmmac: use sysfs_streq() instead of strncmp()") Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Acked-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Link: https://lore.kernel.org/r/20221125105304.3012153-1-vladimir.oltean@nxp.comSigned-off-by:
-
Davide Tronchin authored
Add CDC-ECM support for LARA-L6. LARA-L6 module can be configured (by AT interface) in three different USB modes: * Default mode (Vendor ID: 0x1546 Product ID: 0x1341) with 4 serial interfaces * RmNet mode (Vendor ID: 0x1546 Product ID: 0x1342) with 4 serial interfaces and 1 RmNet virtual network interface * CDC-ECM mode (Vendor ID: 0x1546 Product ID: 0x1343) with 4 serial interface and 1 CDC-ECM virtual network interface In CDC-ECM mode LARA-L6 exposes the following interfaces: If 0: Diagnostic If 1: AT parser If 2: AT parser If 3: AT parset/alternative functions If 4: CDC-ECM interface Signed-off-by:
Davide Tronchin <davide.tronchin.94@gmail.com> Link: https://lore.kernel.org/r/20221124112811.3548-1-davide.tronchin.94@gmail.comSigned-off-by:
-
- 28 Nov, 2022 2 commits
-
-
Suman Ghosh authored
1. Added support to filter packets based on IP fragment. For IPv4 packets check for ip_flag == 0x20 (more fragment bit set). For IPv6 packets check for next_header == 0x2c (next_header set to 'fragment header for IPv6') 2. Added configuration support from both "ethtool ntuple" and "tc flower". Signed-off-by:
Suman Ghosh <sumang@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Sujuan Chen authored
All wed versions should enable the wcid overwritten feature, since the wcid size is controlled by the wlan driver. Tested-by:
Bo Jiao <bo.jiao@mediatek.com> Signed-off-by:
-
- 25 Nov, 2022 23 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueDavid S. Miller authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-11-23 (ice) This series contains updates to ice driver only. Karol adjusts check of PTP hardware to wait longer but check more often. Brett removes use of driver defined link speed; instead using the values from ethtool.h, utilizing static tables for indexing. Ben adds tracking of stats in order to accumulate reported statistics that were previously reset by hardware. Marcin fixes issues setting RXDID when queues are asymmetric. Anatolii re-introduces use of define over magic number; ICE_RLAN_BASE_S. --- v3: - Dropped, previous, patch 2 v2: Patch 5 - Convert some allocations to non-managed - Remove combined error checking; add error checks for each call - Remove excess NULL checks - Remove unnecessary NULL sets and newlines ==================== Signed-off-by: -
David S. Miller authored
Anirudh Venkataramanan says: ==================== net: Remove uses of kmap_atomic() kmap_atomic() is being deprecated. This little series replaces the last few uses of kmap_atomic() in the networking subsystem. This series triggered a suggestion [1] that perhaps the Sun Cassini, LDOM Virtual Switch Driver and the LDOM virtual network drivers should be removed completely. I plan to do this in a follow up patchset. For completeness, this series still includes kmap_atomic() conversions that apply to the above referenced drivers. If for some reason we choose to not remove these drivers, at least they won't be using kmap_atomic() anymore. Also, the following maintainer entries for the Chelsio driver seem to be defunct: Vinay Kumar Yadav <vinay.yadav@chelsio.com> Rohit Maheshwari <rohitm@chelsio.com> I can submit a follow up patch to remove these entries, but thought maybe the folks over at Chelsio would want to look into this first. Changes v1 -> v2: Use memcpy_from_page() in patches 2/6 and 4/6 Add new patch for the thunderbolt driver Update commit messages and cover letter ==================== Signed-off-by: -
Anirudh Venkataramanan authored
kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace kmap_atomic() and kunmap_atomic() with kmap_local_page() and kunmap_local() respectively. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just kmap_local_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Michael Jamet <michael.jamet@intel.com> Cc: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
-
Anirudh Venkataramanan authored
kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace kmap_atomic() and kunmap_atomic() with kmap_local_page() and kunmap_local() respectively. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just kmap_local_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Anirudh Venkataramanan authored
kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace the map-memcpy-unmap usage pattern (done using k[un]map_atomic()) with memcpy_from_page(), which internally uses kmap_local_page() and kunmap_local(). This renders the variable 'vaddr' unnecessary, and so remove this too. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just memcpy_from_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used (via memcpy_from_page()) as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Suggested-by:
Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Anirudh Venkataramanan authored
Pages for Rx buffers are allocated in cas_page_alloc() using either GFP_ATOMIC or GFP_KERNEL. Memory allocated with GFP_KERNEL/GFP_ATOMIC can't come from highmem and so there's no need to kmap() them. Just use page_address() instead. This makes the variable 'addr' unnecessary, so remove it too. Note that kmap_atomic() disables preemption and page-fault processing, but page_address() doesn't. When removing uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just page_address() is used. I don't have hardware, so this change has only been compile tested. Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Signed-off-by:
-
Anirudh Venkataramanan authored
kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace kmap_atomic() and kunmap_atomic() with kmap_local_page() and kunmap_local() respectively. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just kmap_local_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Cc: Edward Cree <ecree.xilinx@gmail.com> Cc: Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Signed-off-by:
-
Anirudh Venkataramanan authored
kmap_atomic() is being deprecated in favor of kmap_local_page(). Replace the map-memcpy-unmap usage pattern (done using k[un]map_atomic()) with memcpy_from_page(), which internally uses kmap_local_page() and kunmap_local(). This renders the variables 'data' and 'vaddr' unnecessary, and so remove these too. Note that kmap_atomic() disables preemption and page-fault processing, but kmap_local_page() doesn't. When converting uses of kmap_atomic(), one has to check if the code being executed between the map/unmap implicitly depends on page-faults and/or preemption being disabled. If yes, then code to disable page-faults and/or preemption should also be added for functional correctness. That however doesn't appear to be the case here, so just memcpy_from_page() is used. Also note that the page being mapped is not allocated by the driver, and so the driver doesn't know if the page is in normal memory. This is the reason kmap_local_page() is used (via memcpy_from_page()) as opposed to page_address(). I don't have hardware, so this change has only been compile tested. Cc: Ayush Sawal <ayush.sawal@chelsio.com> Cc: Ira Weiny <ira.weiny@intel.com> Cc: Fabio M. De Francesco <fmdefrancesco@gmail.com> Suggested-by:
Ayush Sawal <ayush.sawal@chelsio.com> Signed-off-by:
-
David S. Miller authored
Horatiu Vultur says: ==================== net: lan966x: Extend xdp support Extend the current support of XDP in lan966x with the action XDP_TX and XDP_REDIRECT. The first patches just prepare the things such that it would be easier to add XDP_TX and XDP_REDIRECT actions. Like adding XDP_PACKET_HEADROOM, introduce helper functions, use the correct dma_dir for the page pool The last 2 patches introduce the XDP actions XDP_TX and XDP_REDIRECT. v4->v5: - add iterator declaration inside for loops - move the scope of port inside the function lan966x_fdma_rx_alloc_page_pool - create union for skb and xdpf inside struct lan966x_tx_dcb_buf v3->v4: - use napi_consume_skb instead of dev_kfree_skb_any - arrange members in struct lan966x_tx_dcb_buf not to have holes - fix when xdp program is added the check for determining if page pool needs to be recreated was wrong - change type for len in lan966x_tx_dcb_buf to u32 v2->v3: - make sure to update rxq memory model - update the page pool direction if there is any xdp program - in case of action XDP_TX give back to reuse the page - in case of action XDP_REDIRECT, remap the frame and make sure to unmap it when is transmitted. v1->v2: - use skb_reserve of using skb_put and skb_pull - make sure that data_len doesn't include XDP_PACKET_HEADROOM ==================== Signed-off-by: -
Horatiu Vultur authored
Extend lan966x XDP support with the action XDP_REDIRECT. This is similar with the XDP_TX, so a lot of functionality can be reused. Signed-off-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Signed-off-by:
-
Horatiu Vultur authored
Extend lan966x XDP support with the action XDP_TX. In this case when the received buffer needs to execute XDP_TX, the buffer will be moved to the TX buffers. So a new RX buffer will be allocated. When the TX finish with the frame, it would give back the buffer to the page pool. Signed-off-by:
-
Horatiu Vultur authored
To add support for XDP_TX it is required to be able to write to the DMA area therefore it is required that the pages will be mapped using DMA_BIDIRECTIONAL flag. Therefore check if there are any xdp programs on the interfaces and in that case set DMA_BIDRECTIONAL otherwise use DMA_FROM_DEVICE. Therefore when a new XDP program is added it is required to redo the page_pool. Signed-off-by:
-
Horatiu Vultur authored
By default the rxq memory model is MEM_TYPE_PAGE_SHARED but to be able to reuse pages on the TX side, when the XDP action XDP_TX it is required to update the memory model to PAGE_POOL. Signed-off-by:
-
Horatiu Vultur authored
Currently when a frame was transmitted, it is required to unamp the frame that was transmitted. The length of the frame was taken from the transmitted skb. In the future we might not have an skb, therefore store the length skb directly in the lan966x_tx_dcb_buf and use this one to unamp the frame. While at this, also arrange the members in lan966x_tx_dcb_buf not to have any holes. Signed-off-by:
-
Horatiu Vultur authored
Introduce lan966x_fdma_tx_setup_dcb and lan966x_fdma_tx_start functions and use of them inside lan966x_fdma_xmit. There is no functional change in here. They are introduced to be used when XDP_TX/REDIRECT actions are introduced. Signed-off-by:
-
Horatiu Vultur authored
Update the page_pool params to allocate XDP_PACKET_HEADROOM space as headroom for all received frames. This is needed for when the XDP_TX and XDP_REDIRECT are implemented. Signed-off-by:
-
Min Li authored
PEROUT_ENABLE_OUTPUT_MASK was there to allow us to enable/disable all the perout pins. But it is not standard procedure, we will have to discard it. Signed-off-by:
Min Li <min.li.xe@renesas.com> Signed-off-by:
-
Min Li authored
82P33 family of chips can trigger TOD read/write by external signal from one of the IN12/13/14 pins, which are set user space programs by calling PTP_PIN_SETFUNC through ptp_ioctl Signed-off-by:
-
David S. Miller authored
Steen Hegelund says: ==================== net: TC protocol all support in Sparx5 IS2 VCAP This provides support for the TC flower filters 'protocol all' clause in the Sparx5 IS2 VCAP. It builds on top of the initial IS2 VCAP support found in these series: https://lore.kernel.org/all/20221020130904.1215072-1-steen.hegelund@microchip.com/ https://lore.kernel.org/all/20221109114116.3612477-1-steen.hegelund@microchip.com/ https://lore.kernel.org/all/20221111130519.1459549-1-steen.hegelund@microchip.com/ https://lore.kernel.org/all/20221117213114.699375-1-steen.hegelund@microchip.com/ Functionality: ============== As the configuration for the Sparx5 IS2 VCAP consists of one (or more) keyset(s) for each lookup/port per traffic classification, it is not always possible to cover all protocols with just one ordinary VCAP rule. To improve this situation the driver will try to find out what keysets a rule will need to cover a TC flower "protocol all" filter and then compare this set of keysets to what the hardware is currently configured for. In case multiple keysets are needed then the driver can create a rule per rule size (e.g. X6 and X12) and use a mask on the keyset type field to allow the VCAP to match more than one keyset with just one rule. This is possible because the keysets that have the same size typically has many keys in common, so the VCAP rule keys can make a common match. The result is that one TC filter command may create multiple IS2 VCAP rules of different sizes that have a type field with a masked type id. Delivery: ========= This is current plan for delivering the full VCAP feature set of Sparx5: - Sparx5 IS0 VCAP support - TC policer and drop action support (depends on the Sparx5 QoS support upstreamed separately) - Sparx5 ES0 VCAP support - TC flower template support - TC matchall filter support for mirroring and policing ports - TC flower filter mirror action support - Sparx5 ES2 VCAP support Version History: ================ v2 Fixed a NULL return value compiler warning. Moved the new vcap_find_actionfield function a bit up in the file. v1 Initial version ==================== Signed-off-by:
-
Steen Hegelund authored
This tests the filtering of keys, either dropping unsupported keys or dropping keys specified in a list. Signed-off-by:
Steen Hegelund <steen.hegelund@microchip.com> Signed-off-by:
-
Steen Hegelund authored
This will display a list of keyset in case the type_id field in the VCAP rule has been wildcarded. Signed-off-by:
-
Steen Hegelund authored
This allows support of TC protocol all for the Sparx5 IS2 VCAP. This is done by creating multiple rules that covers the rule size and traffic types in the IS2. Each rule size (e.g X16 and X6) may have multiple keysets and if there are more than one the type field in the VCAP rule will be wildcarded to support these keysets. Signed-off-by:
-
Steen Hegelund authored
This adds support for making a copy of a rule and modify keys and actions to differentiate the copy. Signed-off-by:
-
