- 12 Dec, 2022 23 commits
-
-
Geert Uytterhoeven authored
According to the bindings, only two channels are supported. However, R-Car V3U supports eight, leading to "make dtbs" failures: arch/arm64/boot/dts/renesas/r8a779a0-falcon.dtb: can@e6660000: Unevaluated properties are not allowed ('channel2', 'channel3', 'channel4', 'channel5', 'channel6', 'channel7' were unexpected) Update the number of channels to 8 on R-Car V3U. While at it, prevent adding more properties to the channel nodes, as they must contain no other properties than a status property. Fixes: d6254d52 ("dt-bindings: can: renesas,rcar-canfd: Document r8a779a0 support") Signed-off-by:Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/all/7d41d72cd7db2e90bae069ce57dbb672f17500ae.1670431681.git.geert+renesas@glider.beSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Marc Kleine-Budde authored
Add support for SO_MARK to the CAN_RAW protocol. This makes it possible to add traffic control filters based on the fwmark. Link: https://lore.kernel.org/all/20221210113653.170346-1-mkl@pengutronix.deAcked-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Vivek Yadav authored
When we try to access the mcan message ram addresses during the probe, hclk is gated by any other drivers or disabled, because of that probe gets failed. Move the mram init functionality to mcan chip config called by m_can_start from mcan open function, by that time clocks are enabled. Suggested-by:
Vivek Yadav <vivek.2311@samsung.com> Link: https://lore.kernel.org/all/20221207100632.96200-2-vivek.2311@samsung.comSigned-off-by:
-
Marc Kleine-Budde authored
Vincent Mailhol <mailhol.vincent@wanadoo.fr> says: The gs_can and ucan drivers keep a pointer to struct usb_interface in their private structure. This is not needed. For gs_can the only use is to retrieve struct usb_device, which is already available in gs_usb::udev. For ucan, the field is set but never used. Remove the struct usb_interface fields and clean up. Link: https://lore.kernel.org/all/20221208081142.16936-1-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
The iface field of struct gs_can is only used to retrieve the usb_device which is already available in gs_can::udev. Replace each occurrence of interface_to_usbdev(dev->iface) with dev->udev. This done, remove gs_can::iface. Signed-off-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20221208081142.16936-3-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
Field intf of struct ucan_priv is set but never used. Remove it. Signed-off-by:
-
Ye Bin authored
Since commit bdfb5765 remove NULL-ptr checks from users of can_dev_rcv_lists_find(). 'err' parameter is useless, so remove it. Signed-off-by:
Ye Bin <yebin10@huawei.com> Link: https://lore.kernel.org/all/20221208090940.3695670-1-yebin@huaweicloud.comSigned-off-by:
-
Xu Panda authored
The implementation of strscpy() is more robust and safer. That's now the recommended way to copy NUL terminated strings. Signed-off-by:
Xu Panda <xu.panda@zte.com.cn> Signed-off-by:
Yang Yang <yang.yang29@zte.com> Link: https://lore.kernel.org/all/202212070909095189693@zte.com.cnSigned-off-by:
-
Marc Kleine-Budde authored
Vincent Mailhol <mailhol.vincent@wanadoo.fr> says: The goal of this series is to report the firmware version, the bootloader version and the hardware revision of ETAS ES58x devices. These are already reported in the kernel log but this isn't best practice. Remove the kernel log and instead export all these through devlink. The devlink core automatically exports the firmware and the bootloader version to ethtool, so no need to implement the ethtool_ops::get_drvinfo() callback anymore. Patch one and two implement the core support for devlink (at device level) and devlink port (at the network interface level). Patch three export usb_cache_string() and patch four add a new info attribute to devlink.h. Both are prerequisites for patch five. Patch five is the actual goal: it parses the product information from a custom usb string returned by the device and expose them through devlink. Patch six removes the product information from the kernel log. Finally, patch seven add a devlink documentation page with list all the information attributes reported by the driver. * Sample outputs following this series * | $ devlink dev info | usb/1-9:1.1: | serial_number 0108954 | versions: | fixed: | board.rev B012/000 | running: | fw 04.00.01 | fw.bootloader 02.00.00 | $ devlink port show can0 | usb/1-9:1.1/0: type eth netdev can0 flavour physical port 0 splittable false | $ ethtool -i can0 | driver: etas_es58x | version: 6.1.0-rc7+ | firmware-version: 04.00.01 02.00.00 | expansion-rom-version: | bus-info: 1-9:1.1 | supports-statistics: no | supports-test: no | supports-eeprom-access: no | supports-register-dump: no | supports-priv-flags: no * Changelog * v4 -> v5: https://lore.kernel.org/all/20221130174658.29282-1-mailhol.vincent@wanadoo.fr * [PATH 2/7] add devlink port support. This extends devlink to the network interface. * thanks to devlink port, 'ethtool -i' is now able to retrieve the firmware version from devlink. No need to implement the ethtool_ops::get_drvinfo() callback anymore: remove one patch from the series. * [PATCH 4/7] A new patch to add a new info attribute for the bootloader version in devlink.h. This patch was initially sent as a standalone patch here: https://lore.kernel.org/netdev/20221129031406.3849872-1-mailhol.vincent@wanadoo.fr Merging it to this series so that it is both added and used at the same time. * [PATCH 5/7] use the newly info attribute defined in patch 4/7 to report the bootloader version instead of the custom string "bl". * [PATCH 5/7] because the series does not implement ethtool_ops::get_drvinfo() anymore, the two helper functions es58x_sw_version_is_set() and es58x_hw_revision_is_set() are only used in devlink.c. Move them from es58x_core.h to es58x_devlink.c. * [PATCH 5/7] small rework of the helper function es58x_hw_revision_is_set(): it is OK to only check the letter (if the letter is '\0', it will not be possible to print the next numbers). * [PATCH 5/7 and 6/7] add reviewed-by Andrew Lunn tag. * [PATCH 7/7] Now, 'ethtool -i' reports both the firmware version and the bootloader version (this is how the core export the information from devlink to ethtool). Update the documentation to reflect this fact. * Reoder the patches. v3 -> v4: https://lore.kernel.org/all/20221126162211.93322-1-mailhol.vincent@wanadoo.fr * major rework to use devlink instead of sysfs following Andrew's comment. * split the series in 6 patches. * [PATCH 1/6] add Acked-by: Greg Kroah-Hartman v2 -> v3: https://lore.kernel.org/all/20221113040108.68249-1-mailhol.vincent@wanadoo.fr * patch 2/3: do not spam the kernel log anymore with the product number. Instead parse the product information string, extract the firmware version, the bootloadar version and the hardware revision and export them through sysfs. * patch 2/3: rework the parsing in order not to need additional fields in struct es58x_parameters. * patch 3/3: only populate ethtool_drvinfo::fw_version because since commit edaf5df2 ("ethtool: ethtool_get_drvinfo: populate drvinfo fields even if callback exits"), there is no need to populate ethtool_drvinfo::driver and ethtool_drvinfo::bus_info in the driver. v1 -> v2: https://lore.kernel.org/all/20221104171604.24052-1-mailhol.vincent@wanadoo.fr * was a single patch. It is now a series of three patches. * add a first new patch to export usb_cache_string(). * add a second new patch to apply usb_cache_string() to existing code. * add missing check on product info string to prevent a buffer overflow. * add comma on the last entry of struct es58x_parameters. v1: https://lore.kernel.org/all/20221104073659.414147-1-mailhol.vincent@wanadoo.fr Link: https://lore.kernel.org/all/20221130174658.29282-1-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
List all the version information reported by the etas_es58x driver through devlink. Also, update MAINTAINERS with the newly created file. Signed-off-by:
-
Vincent Mailhol authored
Now that the product information are available under devlink, no more need to print them in the kernel log. Remove es58x_get_product_info(). Signed-off-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/all/20221130174658.29282-7-mailhol.vincent@wanadoo.frSigned-off-by:
-
Vincent Mailhol authored
ES58x devices report below product information through a custom usb string: * the firmware version * the bootloader version * the hardware revision Parse this string, store the results in struct es58x_dev, export: * the firmware version through devlink's "fw" name * the bootloader version through devlink's "fw.bootloader" name * the hardware revisionthrough devlink's "board.rev" name Those devlink entries are not critical to use the device, if parsing fails, print an informative log message and continue to probe the device. In addition to that, use usb_device::serial to report the device serial number. Signed-off-by:
-
Vincent Mailhol authored
As discussed in [1], abbreviating the bootloader to "bl" might not be well understood. Instead, a bootloader technically being a firmware, name it "fw.bootloader". Add a new macro to devlink.h to formalize this new info attribute name and update the documentation. [1] https://lore.kernel.org/netdev/20221128142723.2f826d20@kernel.org/Suggested-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
-
Minghao Chi authored
Convert platform_get_resource(), devm_ioremap_resource() to a single call to devm_platform_get_and_ioremap_resource(), as this is exactly what this function does. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Link: https://lore.kernel.org/all/202211111443005202576@zte.com.cnSigned-off-by:
-
Vincent Mailhol authored
usb_cache_string() can also be useful for the drivers so export it. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/all/20221130174658.29282-4-mailhol.vincent@wanadoo.frSigned-off-by:
-
Lad Prabhakar authored
The CANFD block on the RZ/Five SoC is identical to one found on the RZ/G2UL SoC. "renesas,r9a07g043-canfd" compatible string will be used on the RZ/Five SoC so to make this clear, update the comment to include RZ/Five SoC. No driver changes are required as generic compatible string "renesas,rzg2l-canfd" will be used as a fallback on RZ/Five SoC. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Acked-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
Vincent Mailhol authored
Add support for devlink port which extends the devlink support to the network interface level. For now, the etas_es58x driver will only rely on the default features that devlink port has to offer and not implement additional feature ones. Signed-off-by:
-
Haibo Chen authored
Add a new compatible string for imx93. Signed-off-by:
Haibo Chen <haibo.chen@nxp.com> Acked-by:
-
Vincent Mailhol authored
Add basic support for devlink at the device level. The callbacks of struct devlink_ops will be implemented next. Signed-off-by:
-
Haibo Chen authored
IMX93 do not contain a GPR to config the stop mode, it will set the flexcan into stop mode automatically once the ARM core go into low power mode (WFI instruct) and gate off the flexcan related clock automatically. But to let these logic work as expect, before ARM core go into low power mode, need to make sure the flexcan related clock keep on. To support stop mode and wakeup feature on imx93, this patch add a new fsl_imx93_devtype_data to separate from imx8mp. Signed-off-by:
-
Vincent Mailhol authored
Follow the best practices, reorder the includes. While doing so, bump up copyright year of each modified files. Signed-off-by:
-
Jean Delvare authored
Since commit 0166dc11 ("of: make CONFIG_OF user selectable"), it is possible to test-build any driver which depends on OF on any architecture by explicitly selecting OF. Therefore depending on COMPILE_TEST as an alternative is no longer needed. It is actually better to always build such drivers with OF enabled, so that the test builds are closer to how each driver will actually be built on its intended target. Building them without OF may not test much as the compiler will optimize out potentially large parts of the code. In the worst case, this could even pop false positive warnings. Dropping COMPILE_TEST here improves the quality of our testing and avoids wasting time on non-existent issues. Signed-off-by:
Jean Delvare <jdelvare@suse.de> Cc: Pavel Pisa <pisa@cmp.felk.cvut.cz> Cc: Ondrej Ille <ondrej.ille@gmail.com> Acked-by:
Pavel Pisa <pisa@cmp.felk.cvut.cz> Link: https://lore.kernel.org/all/20221124141604.4265225f@endymion.delvareSigned-off-by:
-
Marc Kleine-Budde authored
Biju Das <biju.das.jz@bp.renesas.com> says: The CAN FD IP found on RZ/G2L SoC has some HW features different to that of R-Car. For example, it has multiple resets, dedicated channel tx and error interrupts, separate global rx and error interrupts compared to shared irq for R-Car. it does not s ECC error flag registers and clk post divider present on R-Car. Similarly, R-Car V3U has 8 channels whereas other SoCs has only 2 channels. Currently all the HW differences are handled by comparing with chip_id enum. This patch series aims to replace chip_id with struct rcar_canfd_hw_info to handle the HW feature differences and driver data present on both IPs. The changes are trivial and tested on RZ/G2L SMARC EVK. This patch series depend upon [1]. [1] https://lore.kernel.org/all/20221025155657.1426948-1-biju.das.jz@bp.renesas.com changes since v2: https://lore.kernel.org/all/20221026131732.1843105-1-biju.das.jz@bp.renesas.com * Replaced data type of max_channels from unsigned int->u8 to save memory. * Replaced data type of postdiv from unsigned int->u8 to save memory. changes since v1: https://lore.kernel.org/all/20221022104357.1276740-1-biju.das.jz@bp.renesas.com * Updated commit description for R-Car V3U SoC detection using driver data. * Replaced data type of max_channels from u32->unsigned int. * Replaced multi_global_irqs->shared_global_irqs to make it positive checks. * Replaced clk_postdiv->postdiv driver data variable. * Simplified the calcualtion for fcan_freq. * Replaced info->has_gerfl to gpriv->info->has_gerfl and wrapped the ECC error flag checks inside a single if statement. * Added Rb tag from Geert patch#1,#2,#3 and #5 Link: https://lore.kernel.org/all/20221027082158.95895-1-biju.das.jz@bp.renesas.com [mkl: only take patches 1...5 to avoid merge conflict] Signed-off-by:
-
- 10 Dec, 2022 17 commits
-
-
Biju Das authored
RZ/G2L has separate IRQ lines for tx and error interrupt for each channel whereas R-Car has a combined IRQ line for all the channel specific tx and error interrupts. Add multi_channel_irqs to struct rcar_canfd_hw_info to select the driver to choose between combined and separate irq registration for channel interrupts. This patch also removes enum rcanfd_chip_id and chip_id from both struct rcar_canfd_hw_info, as it is unused. Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
-
Biju Das authored
R-Car has a clock divider for CAN FD clock within the IP, whereas it is not available on RZ/G2L. Add postdiv variable to struct rcar_canfd_hw_info to take care of this difference. Signed-off-by:
-
Biju Das authored
RZ/G2L has separate IRQ lines for receive FIFO and global error interrupt whereas R-Car has shared IRQ line. Add shared_global_irqs to struct rcar_canfd_hw_info to select the driver to choose between shared and separate irq registration for global interrupts. Signed-off-by:
-
Biju Das authored
R-Car V3U supports a maximum of 8 channels whereas rest of the SoCs support 2 channels. Add max_channels variable to struct rcar_canfd_hw_info to handle this difference. Signed-off-by:
-
Vivek Yadav authored
Sort header inclusion alphabetically. Suggested-by:
-
Biju Das authored
The CAN FD IP found on RZ/G2L SoC has some HW features different to that of R-Car. For example, it has multiple resets and multiple IRQs for global and channel interrupts. Also, it does not have ECC error flag registers and clk post divider present on R-Car. Similarly, R-Car V3U has 8 channels whereas other SoCs has only 2 channels. This patch adds the struct rcar_canfd_hw_info to take care of the HW feature differences and driver data present on both IPs. It also replaces the driver data chip type with struct rcar_canfd_hw_info by moving chip type to it. Whilst started using driver data instead of chip_id for detecting R-Car V3U SoCs. Signed-off-by:
-
Marc Kleine-Budde authored
Fix coding style by removing empty lines in variable declaration. Fixes: 39d3df6b ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Cc: Jimmy Assarsson <extja@kvaser.com> Cc: Anssi Hannula <anssi.hannula@bitwise.fi> Link: https://lore.kernel.org/all/20221031114513.81214-2-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The variable err is initialized, but the initialized value is Overwritten before it is read. Fix the warning by not initializing the variable err at all. Fixes: 39d3df6b ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Cc: Jimmy Assarsson <extja@kvaser.com> Cc: Anssi Hannula <anssi.hannula@bitwise.fi> Link: https://lore.kernel.org/all/20221031114513.81214-1-mkl@pengutronix.deSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'ipsec-next-2022-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next Steffen Klassert says: ==================== ipsec-next 2022-12-09 1) Add xfrm packet offload core API. From Leon Romanovsky. 2) Add xfrm packet offload support for mlx5. From Leon Romanovsky and Raed Salem. 3) Fix a typto in a error message. From Colin Ian King. * tag 'ipsec-next-2022-12-09' of git://git.kernel.org/pub/scm/linux/kernel/git/klassert/ipsec-next: (38 commits) xfrm: Fix spelling mistake "oflload" -> "offload" net/mlx5e: Open mlx5 driver to accept IPsec packet offload net/mlx5e: Handle ESN update events net/mlx5e: Handle hardware IPsec limits events net/mlx5e: Update IPsec soft and hard limits net/mlx5e: Store all XFRM SAs in Xarray net/mlx5e: Provide intermediate pointer to access IPsec struct net/mlx5e: Skip IPsec encryption for TX path without matching policy net/mlx5e: Add statistics for Rx/Tx IPsec offloaded flows net/mlx5e: Improve IPsec flow steering autogroup net/mlx5e: Configure IPsec packet offload flow steering net/mlx5e: Use same coding pattern for Rx and Tx flows net/mlx5e: Add XFRM policy offload logic net/mlx5e: Create IPsec policy offload tables net/mlx5e: Generalize creation of default IPsec miss group and rule net/mlx5e: Group IPsec miss handles into separate struct net/mlx5e: Make clear what IPsec rx_err does net/mlx5e: Flatten the IPsec RX add rule path net/mlx5e: Refactor FTE setup code to be more clear net/mlx5e: Move IPsec flow table creation to separate function ... ==================== Link: https://lore.kernel.org/r/20221209093310.4018731-1-steffen.klassert@secunet.comSigned-off-by:
-
Gavrilov Ilia authored
When the resource size changes, the return value of the 'nla_put_u64_64bit' function is not checked. That has been fixed to avoid rechecking at the next step. Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE. Note that this is harmless, we'd error out at the next put(). Signed-off-by:
Ilia.Gavrilov <Ilia.Gavrilov@infotecs.ru> Link: https://lore.kernel.org/r/20221208082821.3927937-1-Ilia.Gavrilov@infotecs.ruSigned-off-by:
-
Kees Cook authored
syzkaller reported: BUG: KASAN: slab-out-of-bounds in __build_skb_around+0x235/0x340 net/core/skbuff.c:294 Write of size 32 at addr ffff88802aa172c0 by task syz-executor413/5295 For bpf_prog_test_run_skb(), which uses a kmalloc()ed buffer passed to build_skb(). When build_skb() is passed a frag_size of 0, it means the buffer came from kmalloc. In these cases, ksize() is used to find its actual size, but since the allocation may not have been made to that size, actually perform the krealloc() call so that all the associated buffer size checking will be correctly notified (and use the "new" pointer so that compiler hinting works correctly). Split this logic out into a new interface, slab_build_skb(), but leave the original 0 checking for now to catch any stragglers. Reported-by: syzbot+fda18eaa8c12534ccb3b@syzkaller.appspotmail.com Link: https://groups.google.com/g/syzkaller-bugs/c/UnIKxTtU5-0/m/-wbXinkgAQAJ Fixes: 38931d89 ("mm: Make ksize() a reporting-only function") Cc: Pavel Begunkov <asml.silence@gmail.com> Cc: pepsipu <soopthegoop@gmail.com> Cc: syzbot+fda18eaa8c12534ccb3b@syzkaller.appspotmail.com Cc: Vlastimil Babka <vbabka@suse.cz> Cc: kasan-dev <kasan-dev@googlegroups.com> Cc: Andrii Nakryiko <andrii@kernel.org> Cc: ast@kernel.org Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Hao Luo <haoluo@google.com> Cc: Jesper Dangaard Brouer <hawk@kernel.org> Cc: John Fastabend <john.fastabend@gmail.com> Cc: jolsa@kernel.org Cc: KP Singh <kpsingh@kernel.org> Cc: martin.lau@linux.dev Cc: Stanislav Fomichev <sdf@google.com> Cc: song@kernel.org Cc: Yonghong Song <yhs@fb.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20221208060256.give.994-kees@kernel.orgSigned-off-by:
-
Jiapeng Chong authored
The function dmadesc_get_addr() is defined in the bcmgenet.c file, but not called elsewhere, so remove this unused function. drivers/net/ethernet/broadcom/genet/bcmgenet.c:120:26: warning: unused function 'dmadesc_get_addr'. Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3401Reported-by:
Abaci Robot <abaci@linux.alibaba.com> Signed-off-by:
Jiapeng Chong <jiapeng.chong@linux.alibaba.com> Link: https://lore.kernel.org/r/20221209033723.32452-1-jiapeng.chong@linux.alibaba.comSigned-off-by:
-
Jakub Kicinski authored
Mat Martineau says: ==================== mptcp: Miscellaneous cleanup Two code cleanup patches for the 6.2 merge window that don't change behavior: Patch 1 makes proper use of nlmsg_free(), as suggested by Jakub while reviewing f8c9dfbd ("mptcp: add pm listener events"). Patch 2 clarifies success status in a few mptcp functions, which prevents some smatch false positives. ==================== Link: https://lore.kernel.org/r/20221209004431.143701-1-mathew.j.martineau@linux.intel.comSigned-off-by:
-
Matthieu Baerts authored
When 'err' is 0, it looks clearer to return '0' instead of the variable called 'err'. The behaviour is then not modified, just a clearer code. By doing this, we can also avoid false positive smatch warnings like this one: net/mptcp/pm_netlink.c:1169 mptcp_pm_parse_pm_addr_attr() warn: missing error code? 'err' Reported-by:
kernel test robot <lkp@intel.com> Reported-by:
Dan Carpenter <error27@gmail.com> Suggested-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Reviewed-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Geliang Tang authored
Use nlmsg_free() instead of kfree_skb() in pm_netlink.c. The SKB's have been created by nlmsg_new(). The proper cleaning way should then be done with nlmsg_free(). For the moment, nlmsg_free() is simply calling kfree_skb() so we don't change the behaviour here. Suggested-by:
Geliang Tang <geliang.tang@suse.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linuxJakub Kicinski authored
Saeed Mahameed says: ==================== mlx5-updates-2022-12-08 1) Support range match action in SW steering Yevgeny Kliteynik says: ======================= The following patch series adds support for a range match action in SW Steering. SW steering is able to match only on the exact values of the packet fields, as requested by the user: the user provides mask for the fields that are of interest, and the exact values to be matched on when the traffic is handled. The following patch series add new type of action - Range Match, where the user provides a field to be matched on and a range of values (min to max) that will be considered as hit. There are several new notions that were implemented in order to support Range Match: - MATCH_RANGES Steering Table Entry (STE): the new STE type that allows matching the packets' fields on the range of values instead of a specific value. - Match Definer: this is a general FW object that defines which fields in the packet will be referenced by the mask and tag of each STE. Match definer ID is part of STE fields, and it defines how the HW needs to interpret the STE's mask/tag values. Till now SW steering used the definers that were managed by FW and implemented the STE layout as described by the HW spec. Now that we're adding a new type of STE, SW steering needs to also be able to define this new STE's layout, and this is do ======================= 2) From OZ add support for meter mtu offload 2.1: Refactor the code to allow both metering and range post actions as a pre-step for adding police mtu offload support. 2.2: Instantiate mtu green/red flow tables with a single match-all rule. Add the green/red actions to the hit/miss table accordingly 2.3: Initialize the meter object with the TC police mtu parameter. Use the hardware range match action feature. 3) From MaorD, support routes with more than 2 nexthops in multipath 4) Michael and Or, improve and extend vport representor counters. * tag 'mlx5-updates-2022-12-08' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux: net/mlx5: Expose steering dropped packets counter net/mlx5: Refactor and expand rep vport stat group net/mlx5e: multipath, support routes with more than 2 nexthops net/mlx5e: TC, add support for meter mtu offload net/mlx5e: meter, add mtu post meter tables net/mlx5e: meter, refactor to allow multiple post meter tables net/mlx5: DR, Add support for range match action net/mlx5: DR, Add function that tells if STE miss addr has been initialized net/mlx5: DR, Some refactoring of miss address handling net/mlx5: DR, Manage definers with refcounts net/mlx5: DR, Handle FT action in a separate function net/mlx5: DR, Rework is_fw_table function net/mlx5: DR, Add functions to create/destroy MATCH_DEFINER general object net/mlx5: fs, add match on ranges API net/mlx5: mlx5_ifc updates for MATCH_DEFINER general object ==================== Link: https://lore.kernel.org/r/20221209001420.142794-1-saeed@kernel.orgSigned-off-by: -
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-12-08 (ice) Jacob Keller says: This series of patches primarily consists of changes to fix some corner cases that can cause Tx timestamp failures. The issues were discovered and reported by Siddaraju DH and primarily affect E822 hardware, though this series also includes some improvements that affect E810 hardware as well. The primary issue is regarding the way that E822 determines when to generate timestamp interrupts. If the driver reads timestamp indexes which do not have a valid timestamp, the E822 interrupt tracking logic can get stuck. This is due to the way that E822 hardware tracks timestamp index reads internally. I was previously unaware of this behavior as it is significantly different in E810 hardware. Most of the fixes target refactors to ensure that the ice driver does not read timestamp indexes which are not valid on E822 hardware. This is done by using the Tx timestamp ready bitmap register from the PHY. This register indicates what timestamp indexes have outstanding timestamps waiting to be captured. Care must be taken in all cases where we read the timestamp registers, and thus all flows which might have read these registers are refactored. The ice_ptp_tx_tstamp function is modified to consolidate as much of the logic relating to these registers as possible. It now handles discarding stale timestamps which are old or which occurred after a PHC time update. This replaces previously standalone thread functions like the periodic work function and the ice_ptp_flush_tx_tracker function. In addition, some minor cleanups noticed while writing these refactors are included. The remaining patches refactor the E822 implementation to remove the "bypass" mode for timestamps. The E822 hardware has the ability to provide a more precise timestamp by making use of measurements of the precise way that packets flow through the hardware pipeline. These measurements are known as "Vernier" calibration. The "bypass" mode disables many of these measurements in favor of a faster start up time for Tx and Rx timestamping. Instead, once these measurements were captured, the driver tries to reconfigure the PHY to enable the vernier calibrations. Unfortunately this recalibration does not work. Testing indicates that the PHY simply remains in bypass mode without the increased timestamp precision. Remove the attempt at recalibration and always use vernier mode. This has one disadvantage that Tx and Rx timestamps cannot begin until after at least one packet of that type goes through the hardware pipeline. Because of this, further refactor the driver to separate Tx and Rx vernier calibration. Complete the Tx and Rx independently, enabling the appropriate type of timestamp as soon as the relevant packet has traversed the hardware pipeline. This was reported by Milena Olech. Note that although these might be considered "bug fixes", the required changes in order to appropriately resolve these issues is large. Thus it does not feel suitable to send this series to net. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: reschedule ice_ptp_wait_for_offset_valid during reset ice: make Tx and Rx vernier offset calibration independent ice: only check set bits in ice_ptp_flush_tx_tracker ice: handle flushing stale Tx timestamps in ice_ptp_tx_tstamp ice: cleanup allocations in ice_ptp_alloc_tx_tracker ice: protect init and calibrating check in ice_ptp_request_ts ice: synchronize the misc IRQ when tearing down Tx tracker ice: check Tx timestamp memory register for ready timestamps ice: handle discarding old Tx requests in ice_ptp_tx_tstamp ice: always call ice_ptp_link_change and make it void ice: fix misuse of "link err" with "link status" ice: Reset TS memory for all quads ice: Remove the E822 vernier "bypass" logic ice: Use more generic names for ice_ptp_tx fields ==================== Link: https://lore.kernel.org/r/20221208213932.1274143-1-anthony.l.nguyen@intel.comSigned-off-by:
-
