- 12 Dec, 2022 40 commits
-
-
Luiz Augusto von Dentz authored
This attempts to program the address stored in hdev->static_addr after the init sequence has been complete: @ MGMT Command: Set Static A.. (0x002b) plen 6 Address: C0:55:44:33:22:11 (Static) @ MGMT Event: Command Complete (0x0001) plen 7 Set Static Address (0x002b) plen 4 Status: Success (0x00) Current settings: 0x00008200 Low Energy Static Address @ MGMT Event: New Settings (0x0006) plen 4 Current settings: 0x00008200 Low Energy Static Address < HCI Command: LE Set Random.. (0x08|0x0005) plen 6 Address: C0:55:44:33:22:11 (Static) > HCI Event: Command Complete (0x0e) plen 4 LE Set Random Address (0x08|0x0005) ncmd 1 Status: Success (0x00) @ MGMT Event: Command Complete (0x0001) plen 7 Set Powered (0x0005) plen 4 Status: Success (0x00) Current settings: 0x00008201 Powered Low Energy Static Address @ MGMT Event: New Settings (0x0006) plen 4 Current settings: 0x00008201 Powered Low Energy Static Address Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> Tested-by: Brian Gix <brian.gix@intel.com>
-
Nicolas Cavallari authored
The USB interface between the host and the bluetooth adapter used for SCO packets uses an USB isochronous endpoint with a fragmentation scheme that does not tolerate errors. Except USB isochronous transfers do not provide a reliable stream with guaranteed delivery. (There is no retry on error, see USB spec v2.0 5.6 and 8.5.5.) To fragment a packet, the bluetooth HCI simply splits it in parts and transfer them as-is. The receiver is expected to reconstruct the packet by assuming the first fragment contains the header and parsing its size field. There is no error detection either. If a fragment is lost, the end result is that the kernel is no longer synchronized and will pass malformed data to the upper layers, since it has no way to tell if the first fragment is an actual first fragment or a continuation fragment. Resynchronization can only happen by luck and requires an unbounded amount of time. The typical symptom for a HSP/HFP bluetooth headset is that the microphone stops working and dmesg contains piles of rate-limited "Bluetooth: hci0: SCO packet for unknown connection handle XXXX" errors for an indeterminate amount of time, until the kernel accidentally resynchronize. A workaround is to ask the upper layer to prevalidate the first fragment header. This is not possible with user channels so this workaround is disabled in this case. This problem is the most severe when using an ath3k adapter on an i.MX 6 board, where packet loss occur regularly, possibly because it is an USB1 device connected on an USB2 hub and this is a special case requiring split transactions. Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Archie Pusaka authored
On cmd_timeout with no reset_gpio, reset the USB port as a last resort. This patch changes the behavior of btusb_intel_cmd_timeout and btusb_rtl_cmd_timeout. Signed-off-by: Archie Pusaka <apusaka@chromium.org> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@google.com> Reviewed-by: Ying Hsu <yinghsu@chromium.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Chethan Tumkur Narayan authored
In case of suspend/resume and HCI_RESET (BT On and Off), ISOC endpoint set to alt setting 0 when no SCO connection exists. This patch shall avoid resetting of ISOC endpoint to alt setting to 0. Signed-off-by: Chethan Tumkur Narayan <chethan.tumkur.narayan@intel.com> Signed-off-by: Kiran K <kiran.k@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
-
Rob Herring authored
Convert the Socionext NetSec Ethernet binding to DT schema format. Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Jassi Brar <jaswinder.singh@linaro.org> Link: https://lore.kernel.org/r/20221209171553.3350583-1-robh@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Taras Chornyi authored
Taras's Marvell email account will be shut down soon so change it to Plvision. Signed-off-by: Taras Chornyi <taras.chornyi@plvision.eu> Signed-off-by: Vadym Kochan <vadym.kochan@plvision.eu> Link: https://lore.kernel.org/r/20221209154521.1246881-1-vadym.kochan@plvision.euSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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> Reviewed-by: Jiri Pirko <jiri@nvidia.com> Link: https://lore.kernel.org/r/202212091538591375035@zte.com.cnSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Firo Yang authored
Recently, a customer reported that from their container whose net namespace is different to the host's init_net, they can't set the container's net.sctp.rto_max to any value smaller than init_net.sctp.rto_min. For instance, Host: sudo sysctl net.sctp.rto_min net.sctp.rto_min = 1000 Container: echo 100 > /mnt/proc-net/sctp/rto_min echo 400 > /mnt/proc-net/sctp/rto_max echo: write error: Invalid argument This is caused by the check made from this'commit 4f3fdf3b ("sctp: add check rto_min and rto_max in sysctl")' When validating the input value, it's always referring the boundary value set for the init_net namespace. Having container's rto_max smaller than host's init_net.sctp.rto_min does make sense. Consider that the rto between two containers on the same host is very likely smaller than it for two hosts. So to fix this problem, as suggested by Marcelo, this patch makes the extra pointers of rto_min, rto_max, pf_retrans, and ps_retrans point to the corresponding variables from the newly created net namespace while the new net namespace is being registered in sctp_sysctl_net_register. Fixes: 4f3fdf3b ("sctp: add check rto_min and rto_max in sysctl") Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Reviewed-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by: Firo Yang <firo.yang@suse.com> Link: https://lore.kernel.org/r/20221209054854.23889-1-firo.yang@suse.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Roger Quadros authored
Ensure pm_runtime_put() is issued in error path. Reported-by: Jakub Kicinski <kuba@kernel.org> Fixes: 93a76530 ("net: ethernet: ti: introduce am65x/j721e gigabit eth subsystem driver") Signed-off-by: Roger Quadros <rogerq@kernel.org> Reviewed-by: Saeed Mahameed <saeed@kernel.org> Link: https://lore.kernel.org/r/20221208105534.63709-1-rogerq@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'wireless-next-2022-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next Kalle Valo says: ==================== wireless-next patches for v6.2 Fourth set of patches for v6.2. Few final patches, a big change is that rtw88 now has USB support. Major changes: rtw88 * support USB devices rtw8821cu, rtw8822bu, rtw8822cu and rtw8723du * tag 'wireless-next-2022-12-12' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (43 commits) wifi: rtl8xxxu: fixing IQK failures for rtl8192eu wifi: rtlwifi: btcoexist: fix conditions branches that are never executed wifi: rtlwifi: rtl8192se: remove redundant rtl_get_bbreg() call wifi: rtw88: Add rtw8723du chipset support wifi: rtw88: Add rtw8822cu chipset support wifi: rtw88: Add rtw8822bu chipset support wifi: rtw88: Add rtw8821cu chipset support wifi: rtw88: Add common USB chip support wifi: rtw88: iterate over vif/sta list non-atomically wifi: rtw88: Drop coex mutex wifi: rtw88: Drop h2c.lock wifi: rtw88: Drop rf_lock wifi: rtw88: Call rtw_fw_beacon_filter_config() with rtwdev->mutex held wifi: rtw88: print firmware type in info message wifi: rtw89: add join info upon create interface wifi: rtw89: fix unsuccessful interface_add flow wifi: rtw89: stop mac port function when stop_ap() wifi: rtw89: add mac TSF sync function wifi: rtw89: request full firmware only once if it's early requested wifi: rtw89: don't request partial firmware if SECURITY_LOADPIN_ENFORCE ... ==================== Link: https://lore.kernel.org/r/20221212093026.5C5AEC433D2@smtp.kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextJakub Kicinski authored
Alexei Starovoitov says: ==================== pull-request: bpf-next 2022-12-11 We've added 74 non-merge commits during the last 11 day(s) which contain a total of 88 files changed, 3362 insertions(+), 789 deletions(-). The main changes are: 1) Decouple prune and jump points handling in the verifier, from Andrii. 2) Do not rely on ALLOW_ERROR_INJECTION for fmod_ret, from Benjamin. Merged from hid tree. 3) Do not zero-extend kfunc return values. Necessary fix for 32-bit archs, from Björn. 4) Don't use rcu_users to refcount in task kfuncs, from David. 5) Three reg_state->id fixes in the verifier, from Eduard. 6) Optimize bpf_mem_alloc by reusing elements from free_by_rcu, from Hou. 7) Refactor dynptr handling in the verifier, from Kumar. 8) Remove the "/sys" mount and umount dance in {open,close}_netns in bpf selftests, from Martin. 9) Enable sleepable support for cgrp local storage, from Yonghong. * tag 'for-netdev' of https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next: (74 commits) selftests/bpf: test case for relaxed prunning of active_lock.id selftests/bpf: Add pruning test case for bpf_spin_lock bpf: use check_ids() for active_lock comparison selftests/bpf: verify states_equal() maintains idmap across all frames bpf: states_equal() must build idmap for all function frames selftests/bpf: test cases for regsafe() bug skipping check_id() bpf: regsafe() must not skip check_ids() docs/bpf: Add documentation for BPF_MAP_TYPE_SK_STORAGE selftests/bpf: Add test for dynptr reinit in user_ringbuf callback bpf: Use memmove for bpf_dynptr_{read,write} bpf: Move PTR_TO_STACK alignment check to process_dynptr_func bpf: Rework check_func_arg_reg_off bpf: Rework process_dynptr_func bpf: Propagate errors from process_* checks in check_func_arg bpf: Refactor ARG_PTR_TO_DYNPTR checks into process_dynptr_func bpf: Skip rcu_barrier() if rcu_trace_implies_rcu_gp() is true bpf: Reuse freed element in free_by_rcu during allocation selftests/bpf: Bring test_offload.py back to life bpf: Fix comment error in fixup_kfunc_call function bpf: Do not zero-extend kfunc return values ... ==================== Link: https://lore.kernel.org/r/20221212024701.73809-1-alexei.starovoitov@gmail.comSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-11-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-10-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-9-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-8-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-7-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-6-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-5-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
Markus Schneider-Pargmann authored
Only read register PSR if there is an error indicated in irqstatus. Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-4-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-3-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Markus Schneider-Pargmann <msp@baylibre.com> Link: https://lore.kernel.org/all/20221206115728.1056014-2-msp@baylibre.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-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 <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
Field intf of struct ucan_priv is set but never used. Remove it. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20221208081142.16936-2-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20221130174658.29282-8-mailhol.vincent@wanadoo.fr [mkl: fixed version information table: "bl" -> "fw.bootloader" Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/all/20221130174658.29282-7-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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 <mailhol.vincent@wanadoo.fr> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/all/20221130174658.29282-6-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Link: https://lore.kernel.org/all/20221130174658.29282-5-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Marc Kleine-Budde <mkl@pengutronix.de>
-
Vincent Mailhol authored
usb_cache_string() can also be useful for the drivers so export it. Signed-off-by: Vincent Mailhol <mailhol.vincent@wanadoo.fr> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://lore.kernel.org/all/20221130174658.29282-4-mailhol.vincent@wanadoo.frSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-
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: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/all/20221115123811.1182922-1-prabhakar.mahadev-lad.rj@bp.renesas.comSigned-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
-