- 12 Dec, 2022 40 commits
-
-
David S. Miller authored
Merge tag 'linux-can-next-for-6.2-20221212' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== linux-can-next-for-6.2-20221212 this is a pull request of 39 patches for net-next/master. The first 2 patches are by me fix a warning and coding style in the kvaser_usb driver. Vivek Yadav's patch sorts the includes of the m_can driver. Biju Das contributes 5 patches for the rcar_canfd driver improve the support for different IP core variants. Jean Delvare's patch for the ctucanfd drops the dependency on COMPILE_TEST. Vincent Mailhol's patch sorts the includes of the etas_es58x driver. Haibo Chen's contributes 2 patches that add i.MX93 support to the flexcan driver. Lad Prabhakar's patch updates the dt-bindings documentation of the rcar_canfd driver. Minghao Chi's patch converts the c_can platform driver to devm_platform_get_and_ioremap_resource(). In the next 7 patches Vincent Mailhol adds devlink support to the etas_es58x driver to report firmware, bootloader and hardware version. Xu Panda's patch converts a strncpy() -> strscpy() in the ucan driver. Ye Bin's patch removes a useless parameter from the AF_CAN protocol. The next 2 patches by Vincent Mailhol and remove unneeded or unused pointers to struct usb_interface in device's priv struct in the ucan and gs_usb driver. Vivek Yadav's patch cleans up the usage of the RAM initialization in the m_can driver. A patch by me add support for SO_MARK to the AF_CAN protocol. Geert Uytterhoeven's patch fixes the number of CAN channels in the rcan_canfd bindings documentation. In the last 11 patches Markus Schneider-Pargmann optimizes the register access in the t_can driver and cleans up the tcan glue driver. ==================== Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Marc Kleine-Budde authored
Markus Schneider-Pargmann <msp@baylibre.com> says: as requested I split the series into two parts. This is the first parts with simple improvements to reduce the number of SPI transfers. The second part will be the rest with coalescing support and more complex optimizations. Changes since v1: https://lore.kernel.org/all/20221116205308.2996556-1-msp@baylibre.com - Fixed register ranges - Added fixes: tag for two patches Link: https://lore.kernel.org/all/20221206115728.1056014-1-msp@baylibre.comSigned-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Markus Schneider-Pargmann authored
Specify exactly which registers are read/writeable in the chip. This is supposed to help detect any violations in the future. Signed-off-by:
Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-12-msp@baylibre.comSigned-off-by:
-
Markus Schneider-Pargmann authored
According to the datasheet 0x10 is the last register in the first block, not register 0x2c. The datasheet lists the last register of the second block as 0x830, not 0x83c. Signed-off-by:
-
Markus Schneider-Pargmann authored
TCAN4X5X_ERROR_STATUS is not a status register that needs clearing during interrupt handling. Instead this is a masking register that masks error interrupts. Writing TCAN4X5X_CLEAR_ALL_INT to this register effectively masks everything. Rename the register and mask all error interrupts only once by writing to the register in tcan4x5x_init. Fixes: 5443c226 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Signed-off-by:
-
Markus Schneider-Pargmann authored
Register 0x824 TCAN4X5X_MCAN_INT_REG is a read-only register. Any writes to this register do not have any effect. Remove this write. The m_can driver aldready clears the interrupts in m_can_isr() by writing to M_CAN_IR which is translated to register 0x1050 which is a writable version of this register. Fixes: 5443c226 ("can: tcan4x5x: Add tcan4x5x driver to the kernel") Signed-off-by:
-
Markus Schneider-Pargmann authored
Instead of acknowledging every item of the fifo, only acknowledge the last item read. This behavior is documented in the datasheet. The new getindex will be the acknowledged item + 1. Signed-off-by:
-
Markus Schneider-Pargmann authored
Transmit events from the txe fifo can be batch acknowledged by acknowledging the last read txe fifo item. This will save txe_count writes which is important for peripheral chips. Signed-off-by:
-
Markus Schneider-Pargmann authored
The getindex gets increased by one every time. We can calculate the correct getindex in the driver and avoid the additional reads of rxfs. Signed-off-by:
-
Markus Schneider-Pargmann authored
The getindex simply increases by one for every iteration. There is no need to get the current getidx every time from a register. Instead we can just count and wrap if necessary. Signed-off-by:
-
Markus Schneider-Pargmann authored
Only read register PSR if there is an error indicated in irqstatus. Signed-off-by:
-
Markus Schneider-Pargmann authored
For peripheral devices the m_can_rx_handler is called directly after setting cdev->irqstatus. This means we don't have to read the irqstatus again in m_can_rx_handler. Avoid this by adding a parameter that is false for direct calls. Signed-off-by:
-
Markus Schneider-Pargmann authored
The TXFQS register is read first to check if the fifo is full and then immediately again to get the putidx. This is unnecessary and adds significant overhead if read requests are done over a slow bus, for example SPI with tcan4x5x. Add a variable to store the value of the register. Split the m_can_tx_fifo_full function into two to avoid the hidden m_can_read call if not needed. Signed-off-by:
-
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 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:
-
David S. Miller authored
Xin Long says: ==================== net: eliminate the duplicate code in the ct nat functions of ovs and tc The changes in the patchset: "net: add helper support in tc act_ct for ovs offloading" had moved some common ct code used by both OVS and TC into netfilter. There are still some big functions pretty similar defined and used in each of OVS and TC. It is not good to maintain such big function in 2 places. This patchset is to extract the functions for NAT processing from OVS and TC to netfilter. To make this change clear and safe, this patchset gets the common code out of OVS and TC step by step: The patch 1-4 make some minor changes in OVS and TC to make the NAT code of them completely the same, then the patch 5 moves the common code to the netfilter and exports one function called by each of OVS and TC. v1->v2: - Create nf_nat_ovs.c to include the nat functions, as Pablo suggested. v2->v3: - fix a typo in subject of patch 2/5, as Marcelo noticed. - fix in openvswitch to keep OVS ct nat and TC ct nat consistent in patch 3/5 instead of in tc, as Marcelo noticed. - use BIT(var) macro instead of (1 << var) in patch 5/5, as Marcelo suggested. - use ifdef in netfilter/Makefile to build nf_nat_ovs only when OVS or TC ct action is enabled in patch 5/5, as Marcelo suggested. v3->v4: - add NF_NAT_OVS in netfilter/Kconfig and add select NF_NAT_OVS in OVS and TC Kconfig instead of using ifdef in netfilter/Makefile, as Pablo suggested. ==================== Signed-off-by: -
Xin Long authored
There are two nat functions are nearly the same in both OVS and TC code, (ovs_)ct_nat_execute() and ovs_ct_nat/tcf_ct_act_nat(). This patch creates nf_nat_ovs.c under netfilter and moves them there then exports nf_ct_nat() so that it can be shared by both OVS and TC, and keeps the nat (type) check and nat flag update in OVS and TC's own place, as these parts are different between OVS and TC. Note that in OVS nat function it was using skb->protocol to get the proto as it already skips vlans in key_extract(), while it doesn't in TC, and TC has to call skb_protocol() to get proto. So in nf_ct_nat_execute(), we keep using skb_protocol() which works for both OVS and TC contrack. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Acked-by:
Aaron Conole <aconole@redhat.com> Acked-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Xin Long authored
In ovs_ct_nat_execute(), the packet flow key nat flags are updated when it processes ICMP(v6) error packets translation successfully. In ct_nat_execute() when processing ICMP(v6) error packets translation successfully, it should have done the same in ct_nat_execute() to set post_ct_s/dnat flag, which will be used to update flow key nat flags in OVS module later. Reviewed-by:
Saeed Mahameed <saeed@kernel.org> Signed-off-by:
-
Xin Long authored
When it fails to allocate nat ext, the packet should be dropped, like the memory allocation failures in other places in ovs_ct_nat(). This patch changes to return NF_DROP when fails to add nat ext before doing NAT in ovs_ct_nat(), also it would keep consistent with tc action ct' processing in tcf_ct_act_nat(). Signed-off-by:
-
