aboutsummaryrefslogtreecommitdiff
path: root/drivers/net
AgeCommit message (Collapse)AuthorFilesLines
2022-07-28can: peak_usb: advertise timestamping capabilities and add ioctl supportVincent Mailhol5-0/+45
Currently, userland has no method to query which timestamping features are supported by the peak_usb driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way to add hardware timestamp support is to implement ethtool_ops::get_ts_info() in order to advertise the timestamping capabilities and to implement net_device_ops::ndo_eth_ioctl() as requested in [1]. Currently, the driver only supports hardware RX timestamps [2] but not hardware TX. For this reason, the generic function can_ethtool_op_get_ts_info_hwts() and can_eth_ioctl_hwts() can not be reused and instead this patch adds pcan_get_ts_info() and peak_eth_ioctl(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers [2] https://lore.kernel.org/linux-can/[email protected]/ CC: Stephane Grosjean <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: peak_canfd: advertise timestamping capabilities and add ioctl supportVincent Mailhol1-0/+48
Currently, userland has no method to query which timestamping features are supported by the peak_canfd driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way to add hardware timestamp support is to implement ethtool_ops::get_ts_info() in order to advertise the timestamping capabilities and to implement net_device_ops::ndo_eth_ioctl() as requested in [1]. Currently, the driver only supports hardware RX timestamps [2] but not hardware TX. For this reason, the generic function can_ethtool_op_get_ts_info_hwts() and can_eth_ioctl_hwts() can not be reused and instead this patch adds peak_get_ts_info() and peak_eth_ioctl(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers [2] https://lore.kernel.org/linux-can/[email protected]/ CC: Stephane Grosjean <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: kvaser_usb: advertise timestamping capabilities and add ioctl supportVincent Mailhol2-2/+26
Currently, userland has no method to query which timestamping features are supported by the kvaser_usb driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers CC: Jimmy Assarsson <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: kvaser_pciefd: advertise timestamping capabilities and add ioctl supportVincent Mailhol1-0/+7
Currently, userland has no method to query which timestamping features are supported by the kvaser_pciefd driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers CC: Jimmy Assarsson <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: etas_es58x: advertise timestamping capabilities and add ioctl supportVincent Mailhol1-1/+8
Currently, userland has no method to query which timestamping features are supported by the etas_es58x driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping is supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: mcp251xfd: advertise timestamping capabilities and add ioctl supportVincent Mailhol2-0/+2
Currently, userland has no methods to query which timestamping features are supported by the mcp251xfd driver (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertise what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). Here, we use the CAN specific can_ethtool_op_get_ts_info_hwts() function to achieve this. In addition, the driver currently does not support the hardware timestamps ioctls. According to [1], SIOCSHWTSTAMP is "must" and SIOCGHWTSTAMP is "should". This patch fills up that gap by implementing net_device_ops::ndo_eth_ioctl() using the CAN specific function can_eth_ioctl_hwts(). [1] kernel doc Timestamping, section 3.1: "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add generic function can_eth_ioctl_hwts()Vincent Mailhol1-0/+29
Tools based on libpcap (such as tcpdump) expect the SIOCSHWTSTAMP ioctl call to be supported. This is also specified in the kernel doc [1]. The purpose of this ioctl is to toggle the hardware timestamps. Currently, CAN devices which support hardware timestamping have those always activated. can_eth_ioctl_hwts() is a dumb function that will always succeed when requested to set tx_type to HWTSTAMP_TX_ON or rx_filter to HWTSTAMP_FILTER_ALL. [1] Kernel doc: Timestamping, section 3.1 "Hardware Timestamping Implementation: Device Drivers" Link: https://docs.kernel.org/networking/timestamping.html#hardware-timestamping-implementation-device-drivers Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add generic function can_ethtool_op_get_ts_info_hwts()Vincent Mailhol1-0/+21
Add function can_ethtool_op_get_ts_info_hwts(). This function will be used by CAN devices with hardware TX/RX timestamping support to implement ethtool_ops::get_ts_info. This function does not offer support to activate/deactivate hardware timestamps at device level nor support the filter options (which is currently the case for all CAN devices with hardware timestamping support). The fact that hardware timestamp can not be deactivated at hardware level does not impact the userland. As long as the user do not set SO_TIMESTAMPING using a setsockopt() or ioctl(), the kernel will not emit TX timestamps (RX timestamps will still be reproted as it is the case currently). Drivers which need more fine grained control remains free to implement their own function, but we foresee that the generic function introduced here will be sufficient for the majority. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: dev: add hardware TX timestampVincent Mailhol1-0/+6
Because of the loopback feature of socket CAN, hardware TX timestamps are nothing else than the hardware RX timespamp of the corresponding loopback packet. This patch simply reuses the hardware RX timestamp. The rationale to clone this timestamp value is that existing tools which rely of libpcap (such as tcpdump) expect support for both TX and RX hardware timestamps in order to activate the feature (i.e. no granular control to activate either of TX or RX hardware timestamps). Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: tree-wide: advertise software timestamping capabilitiesVincent Mailhol30-0/+159
Currently, some CAN drivers support hardware timestamping, some do not. But userland has no method to query which features are supported (aside maybe of getting RX messages and observe whether or not hardware timestamps stay at zero). The canonical way for a network driver to advertised what kind of timestamping it supports is to implement ethtool_ops::get_ts_info(). This patch only targets the CAN drivers which *do not* support hardware timestamping. For each of those CAN drivers, implement the get_ts_info() using the generic ethtool_op_get_ts_info(). This way, userland can do: | $ ethtool --show-time-stamping canX to confirm the device timestamping capacities. N.B. the drivers which support hardware timestamping will be migrated in separate patches. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] [mkl: mscan: add missing mscan_ethtool_ops] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28Revert "Merge branch 'octeontx2-minor-tc-fixes'"Paolo Abeni1-73/+33
This reverts commit 35d099da41967f114c6472b838e12014706c26e7, reversing changes made to 58d8bcd47ecc55f1ab92320fe36c31ff4d83cc0c. I wrongly applied that to the net-next tree instead of the intended target tree (net). Reverting it on net-next. Signed-off-by: Paolo Abeni <[email protected]>
2022-07-28can: v(x)can: add software tx timestampsVincent Mailhol2-0/+4
TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, vcan and vxcan do not rely on that function and as such do not offer TX timestamping. While it could be arguable whether TX timestamps are really needed for virtual interfaces, we prefer to still add it so that all CAN drivers, without exception, support the software TX timestamps. Add a call to skb_tx_timestamp() in the vcan_tx() and vxcan_xmit() functions so that the modules now support TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: add software tx timestampsVincent Mailhol1-0/+2
TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, slcan does not rely on that function and as such does not offer TX timestamping. Add a call to skb_tx_timestamp() in the slc_xmit() function so that the module now supports TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf CC: Dario Binacchi <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: janz-ican3: add software tx timestampVincent Mailhol1-0/+2
TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, janz-ican3 does not rely on that function but instead implements its own echo_skb logic. As such it does not offer TX timestamping. Add a call to skb_tx_timestamp() in the ican3_put_echo_skb() function so that the module now supports TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: can327: add software tx timestampsVincent Mailhol1-0/+2
TX timestamps were added to the can_put_echo_skb() function of can_dev modules in [1]. However, can327 does not rely on that function and as such does not offer TX timestamping. Add a call to skb_tx_timestamp() in the can327_netdev_start_xmit() function so that the module now supports TX software timestamps. [1] commit 741b91f1b0ea ("can: dev: can_put_echo_skb(): add software tx timestamps") Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=741b91f1b0ea34f00f6a7d4539b767c409291fcf Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28MAINTAINERS: Add maintainer for the slcan driverDario Binacchi1-0/+1
At the suggestion of its author Oliver Hartkopp ([1]), I take over the maintainer-ship and add myself to the authors of the driver. [1] https://lore.kernel.org/all/[email protected] Suggested-by: Oliver Hartkopp <[email protected]> Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: add support for listen-only modeDario Binacchi1-4/+15
For non-legacy, i.e. ip based configuration, add support for listen-only mode. If listen-only is requested send a listen-only ("L\r") command instead of an open ("O\r") command to the adapter. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: use the generic can_change_mtu()Dario Binacchi1-6/+1
It is useless to define a custom function that does nothing but always return the same error code. Better to use the generic can_change_mtu() function. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: change every `slc' occurrence in `slcan'Dario Binacchi1-53/+56
In the driver there are parts of code where the prefix `slc' is used and others where the prefix `slcan' is used instead. The patch replaces every occurrence of `slc' with `slcan', except for the netdev functions where, to avoid compilation conflicts, it was necessary to replace `slc' with `slcan_netdev'. The patch does not make any functional changes. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: remove legacy infrastructureDario Binacchi1-255/+63
Taking inspiration from the drivers/net/can/can327.c driver and at the suggestion of its author Max Staudt, I removed legacy stuff like `SLCAN_MAGIC' and `slcan_devs' resulting in simplification of the code and its maintainability. The use of slcan_devs is derived from a very old kernel, since slip.c is about 30 years old, so today's kernel allows us to remove it. The .hangup() ldisc function, which only called the ldisc .close(), has been removed since the ldisc layer calls .close() in a good place anyway. The old slcanX name has been dropped in order to use the standard canX interface naming. The ioctl SIOCGIFNAME can be used to query the name of the created interface. Furthermore, there are several ways to get stable interfaces names in user space, e.g. udev or systemd-networkd. The `maxdev' module parameter has also been removed. CC: Max Staudt <[email protected]> Signed-off-by: Dario Binacchi <[email protected]> Reviewed-by: Max Staudt <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: remove useless header inclusionsDario Binacchi1-3/+0
Include only the necessary headers. Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-28can: slcan: use KBUILD_MODNAME and define pr_fmt to replace hardcoded namesVincent Mailhol1-6/+8
The driver uses the string "slcan" to populate tty_ldisc_ops::name. KBUILD_MODNAME also evaluates to "slcan". Use KBUILD_MODNAME to get rid on the hardcoded string names. Similarly, the pr_info() and pr_err() hardcoded the "slcan" prefix. Define pr_fmt so that the "slcan" prefix gets automatically added. CC: Dario Binacchi <[email protected]> Signed-off-by: Vincent Mailhol <[email protected]> Signed-off-by: Dario Binacchi <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-27net: dsa: mv88e6xxx: fix speed setting for CPU/DSA portsMarcin Wojtas1-1/+6
Commit 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting") stopped relying on SPEED_MAX constant and hardcoded speed settings for the switch ports and rely on phylink configuration. It turned out, however, that when the relevant code is called, the mac_capabilites of CPU/DSA port remain unset. mv88e6xxx_setup_port() is called via mv88e6xxx_setup() in dsa_tree_setup_switches(), which precedes setting the caps in phylink_get_caps down in the chain of dsa_tree_setup_ports(). As a result the mac_capabilites are 0 and the default speed for CPU/DSA port is 10M at the start. To fix that, execute mv88e6xxx_get_caps() and obtain the capabilities driectly. Fixes: 3c783b83bd0f ("net: dsa: mv88e6xxx: get rid of SPEED_MAX setting") Signed-off-by: Marcin Wojtas <[email protected]> Reviewed-by: Vladimir Oltean <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-27Merge branch '100GbE' of ↵Jakub Kicinski5-48/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-07-26 This series contains updates to ice driver only. Przemyslaw corrects accounting for VF VLANs to allow for correct number of VLANs for untrusted VF. He also correct issue with checksum offload on VXLAN tunnels. Ani allows for two VSIs to share the same MAC address. Maciej corrects checked bits for descriptor completion of loopback * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: do not setup vlan for loopback VSI ice: check (DD | EOF) bits on Rx descriptor rather than (EOP | RS) ice: Fix VSIs unable to share unicast MAC ice: Fix tunnel checksum offload with fragmented traffic ice: Fix max VLANs available for VF ==================== Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-27sfc: disable softirqs for ptp TXAlejandro Lucero1-0/+22
Sending a PTP packet can imply to use the normal TX driver datapath but invoked from the driver's ptp worker. The kernel generic TX code disables softirqs and preemption before calling specific driver TX code, but the ptp worker does not. Although current ptp driver functionality does not require it, there are several reasons for doing so: 1) The invoked code is always executed with softirqs disabled for non PTP packets. 2) Better if a ptp packet transmission is not interrupted by softirq handling which could lead to high latencies. 3) netdev_xmit_more used by the TX code requires preemption to be disabled. Indeed a solution for dealing with kernel preemption state based on static kernel configuration is not possible since the introduction of dynamic preemption level configuration at boot time using the static calls functionality. Fixes: f79c957a0b537 ("drivers: net: sfc: use netdev_xmit_more helper") Signed-off-by: Alejandro Lucero <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Jakub Kicinski <[email protected]>
2022-07-27wifi: plfxlc: Use eth_zero_addr() to assign zero addressXu Qiang1-1/+1
Using eth_zero_addr() to assign zero address instead of memset(). Reported-by: Hulk Robot <[email protected]> Signed-off-by: Xu Qiang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: use existing iftype variable to store the interface typeAjay Singh2-4/+3
For consistency, use an existing 'iftype' element which was already having the interface type. Replace 'mode' with 'iftype' as it was used for the same purpose. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: add 'isinit' flag for SDIO bus similar to SPIAjay Singh4-3/+28
Similar to SPI priv data, add 'isinit' variable in SDIO priv. Make use of the state to invoke hif_init() once, and acquire the lock before accessing hif function. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: cancel the connect operation during interface downAjay Singh3-4/+4
Cancel the ongoing connection request to avoid any issue if the interface is set down before the connection request is completed. host_int_handle_disconnect was already available, so renamed it and used the same API for 'ndio_close' cb. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: get correct length of string WID from received config packetAjay Singh1-2/+3
For string type WID packet, the data length is received as 16-bit value so use 'get_unaligned_le16' conversion API to extract the correct length. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: set station_info flag only when signal value is validAjay Singh1-2/+1
Set station_info->filled to indicate signal level only when its value is received successfully using wilc_get_rssi(). Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: set correct value of 'close' variable in failure caseAjay Singh1-1/+1
Set 'close' variable to '1' to indicate closing operation when initialisation fails during wlan_initialize_threads() call. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wilc1000: add WID_TX_POWER WID in g_cfg_byte arrayAjay Singh1-0/+1
WID_TX_POWER WID value is fetched from the firmware so it should be added in'g_cfg_byte' array to store the data which is received from firmware. Signed-off-by: Ajay Singh <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: b43: do not initialise static variable to 0Xin Gao1-1/+1
No need to initialise static variables to zero. Signed-off-by: Xin Gao <[email protected]> Acked-by: Larry Finger <[email protected]> [[email protected]: improve commit log] Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: b43legacy: clean up one inconsistent indentingYang Li1-1/+1
Eliminate the follow smatch warning: drivers/net/wireless/broadcom/b43legacy/main.c:2947 b43legacy_wireless_core_stop() warn: inconsistent indenting Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: rtl8xxxu: Fix the error handling of the probe functionZheyu Ma1-10/+11
When the driver fails at ieee80211_alloc_hw() at the probe time, the driver will free the 'hw' which is not allocated, causing a bug. The following log can reveal it: [ 15.981294] BUG: KASAN: user-memory-access in mutex_is_locked+0xe/0x40 [ 15.981558] Read of size 8 at addr 0000000000001ab0 by task modprobe/373 [ 15.982583] Call Trace: [ 15.984282] ieee80211_free_hw+0x22/0x390 [ 15.984446] rtl8xxxu_probe+0x3a1/0xab30 [rtl8xxxu] Fix the bug by changing the order of the error handling. Signed-off-by: Zheyu Ma <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wl12xx: Drop if with an always false conditionUwe Kleine-König1-3/+0
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument (in wlcore_probe()) and so wl is never NULL. This is a preparation for making platform remove callbacks return void. Signed-off-by: Uwe Kleine-König <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: libertas: Fix possible refcount leak in if_usb_probe()Hangyu Hua1-0/+1
usb_get_dev will be called before lbs_get_firmware_async which means that usb_put_dev need to be called when lbs_get_firmware_async fails. Fixes: ce84bb69f50e ("libertas USB: convert to asynchronous firmware loading") Signed-off-by: Hangyu Hua <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: mwifiex: clean up one inconsistent indentingYang Li1-1/+1
Eliminate the follow smatch warning: drivers/net/wireless/marvell/mwifiex/pcie.c:3364 mwifiex_unregister_dev() warn: inconsistent indenting Reported-by: Abaci Robot <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27virtio-net: fix the race between refill work and closeJason Wang1-3/+34
We try using cancel_delayed_work_sync() to prevent the work from enabling NAPI. This is insufficient since we don't disable the source of the refill work scheduling. This means an NAPI poll callback after cancel_delayed_work_sync() can schedule the refill work then can re-enable the NAPI that leads to use-after-free [1]. Since the work can enable NAPI, we can't simply disable NAPI before calling cancel_delayed_work_sync(). So fix this by introducing a dedicated boolean to control whether or not the work could be scheduled from NAPI. [1] ================================================================== BUG: KASAN: use-after-free in refill_work+0x43/0xd4 Read of size 2 at addr ffff88810562c92e by task kworker/2:1/42 CPU: 2 PID: 42 Comm: kworker/2:1 Not tainted 5.19.0-rc1+ #480 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: events refill_work Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report.cold+0xbb/0x6ac ? _printk+0xad/0xde ? refill_work+0x43/0xd4 kasan_report+0xa8/0x130 ? refill_work+0x43/0xd4 refill_work+0x43/0xd4 process_one_work+0x43d/0x780 worker_thread+0x2a0/0x6f0 ? process_one_work+0x780/0x780 kthread+0x167/0x1a0 ? kthread_exit+0x50/0x50 ret_from_fork+0x22/0x30 </TASK> ... Fixes: b2baed69e605c ("virtio_net: set/cancel work on ndo_open/ndo_stop") Signed-off-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Reviewed-by: Xuan Zhuo <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2022-07-27can: flexcan: export flexcan_ethtool_ops and remove flexcan_set_ethtool_ops()Vincent Mailhol3-8/+3
The function flexcan_set_ethtool_ops() does one thing: populate net_device::ethtool_ops. Instead, it is possible to directly assign this field and remove one function call and slightly reduce the object size. To do so, export flexcan_ethtool_ops so it becomes visible to flexcan-core.c. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-27can: c_can: export c_can_ethtool_ops and remove c_can_set_ethtool_ops()Vincent Mailhol3-8/+3
The function c_can_set_ethtool_ops() does one thing: populate net_device::ethtool_ops. Instead, it is possible to directly assign this field and remove one function call and slightly reduce the object size. To do so, export c_can_ethtool_ops so it becomes visible to c_can_main.c. Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-27can: slcan: export slcan_ethtool_ops and remove slcan_set_ethtool_ops()Vincent Mailhol3-8/+4
The function slcan_set_ethtool_ops() does one thing: populate net_device::ethtool_ops. Instead, it is possible to directly assign this field and remove one function call and slightly reduce the object size. To do so, export slcan_ethtool_ops so it becomes visible to sclan-core.c. This patch reduces the footprint by 14 bytes: | $ ./scripts/bloat-o-meter drivers/net/can/slcan/slcan.{old,new}.o | drivers/net/can/slcan/slcan.o | add/remove: 0/1 grow/shrink: 1/0 up/down: 15/-29 (-14) | Function old new delta | slcan_open 1010 1025 +15 | slcan_set_ethtool_ops 29 - -29 | Total: Before=11115, After=11101, chg -0.13% Signed-off-by: Vincent Mailhol <[email protected]> Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Marc Kleine-Budde <[email protected]>
2022-07-27wifi: rtlwifi: Remove duplicate word and Fix typoZhang Jiaming1-1/+1
Remove duplicate 'in'. Change 'entrys' to 'entries'. Signed-off-by: Zhang Jiaming <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: mwifiex: Fix comment typoJason Wang1-1/+1
The double `the' is duplicated in line 1540, remove one. Signed-off-by: Jason Wang <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: mwl8k: use time_after to replace "jiffies > a"Li Qiong1-1/+1
time_after deals with timer wrapping correctly. Signed-off-by: Li Qiong <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: iwlwifi: mvm: fix double list_add at iwl_mvm_mac_wake_tx_queueJose Ignacio Tornos Martinez1-0/+1
After successfull station association, if station queues are disabled for some reason, the related lists are not emptied. So if some new element is added to the list in iwl_mvm_mac_wake_tx_queue, it can match with the old one and produce a BUG like this: [ 46.535263] list_add corruption. prev->next should be next (ffff94c1c318a360), but was 0000000000000000. (prev=ffff94c1d02d3388). [ 46.535283] ------------[ cut here ]------------ [ 46.535284] kernel BUG at lib/list_debug.c:26! [ 46.535290] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 46.585304] CPU: 0 PID: 623 Comm: wpa_supplicant Not tainted 5.19.0-rc3+ #1 [ 46.592380] Hardware name: Dell Inc. Inspiron 660s/0478VN , BIOS A07 08/24/2012 [ 46.600336] RIP: 0010:__list_add_valid.cold+0x3d/0x3f [ 46.605475] Code: f2 4c 89 c1 48 89 fe 48 c7 c7 c8 40 67 93 e8 20 cc fd ff 0f 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 70 40 67 93 e8 09 cc fd ff <0f> 0b 48 89 fe 48 c7 c7 00 41 67 93 e8 f8 cb fd ff 0f 0b 48 89 d1 [ 46.624469] RSP: 0018:ffffb20800ab76d8 EFLAGS: 00010286 [ 46.629854] RAX: 0000000000000075 RBX: ffff94c1c318a0e0 RCX: 0000000000000000 [ 46.637105] RDX: 0000000000000201 RSI: ffffffff9365e100 RDI: 00000000ffffffff [ 46.644356] RBP: ffff94c1c5f43370 R08: 0000000000000075 R09: 3064316334396666 [ 46.651607] R10: 3364323064316334 R11: 39666666663d7665 R12: ffff94c1c5f43388 [ 46.658857] R13: ffff94c1d02d3388 R14: ffff94c1c318a360 R15: ffff94c1cf2289c0 [ 46.666108] FS: 00007f65634ff7c0(0000) GS:ffff94c1da200000(0000) knlGS:0000000000000000 [ 46.674331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.680170] CR2: 00007f7dfe984460 CR3: 000000010e894003 CR4: 00000000000606f0 [ 46.687422] Call Trace: [ 46.689906] <TASK> [ 46.691950] iwl_mvm_mac_wake_tx_queue+0xec/0x15c [iwlmvm] [ 46.697601] ieee80211_queue_skb+0x4b3/0x720 [mac80211] [ 46.702973] ? sta_info_get+0x46/0x60 [mac80211] [ 46.707703] ieee80211_tx+0xad/0x110 [mac80211] [ 46.712355] __ieee80211_tx_skb_tid_band+0x71/0x90 [mac80211] ... In order to avoid this problem, we must also remove the related lists when station queues are disabled. Fixes: cfbc6c4c5b91c ("iwlwifi: mvm: support mac80211 TXQs model") Reported-by: Takayuki Nagata <[email protected]> Reported-by: Petr Stourac <[email protected]> Tested-by: Petr Stourac <[email protected]> Signed-off-by: Jose Ignacio Tornos Martinez <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: iwlwifi: mvm: fix clang -Wformat warningsJustin Stitt1-2/+2
When building with Clang we encounter these warnings: | drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1108:47: error: | format specifies type 'unsigned char' but the argument has type 's16' | (aka 'short') [-Werror,-Wformat] IWL_DEBUG_INFO(mvm, "\tburst index: | %hhu\n", res->ftm.burst_index); - | drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1111:47: error: | format specifies type 'unsigned char' but the argument has type 's32' | (aka 'int') [-Werror,-Wformat] IWL_DEBUG_INFO(mvm, "\trssi spread: | %hhu\n", res->ftm.rssi_spread); The previous format specifier `%hhu` describes a u8 but our arguments are wider than this which means bits are potentially being lost. Variadic functions (printf-like) undergo default argument promotion. Documentation/core-api/printk-formats.rst specifically recommends using the promoted-to-type's format flag. As per C11 6.3.1.1: (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf) `If an int can represent all values of the original type ..., the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions.` Thus it makes sense to change `%hhu` to `%d` for both instances of the warning. Link: https://github.com/ClangBuiltLinux/linux/issues/378 Signed-off-by: Justin Stitt <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27wifi: wil6210: debugfs: fix uninitialized variable use in `wil_write_file_wmi()`Ammar Faizi1-2/+2
Commit 7a4836560a61 changes simple_write_to_buffer() with memdup_user() but it forgets to change the value to be returned that came from simple_write_to_buffer() call. It results in the following warning: warning: variable 'rc' is uninitialized when used here [-Wuninitialized] return rc; ^~ Remove rc variable and just return the passed in length if the memdup_user() succeeds. Cc: Dan Carpenter <[email protected]> Reported-by: kernel test robot <[email protected]> Fixes: 7a4836560a6198d245d5732e26f94898b12eb760 ("wifi: wil6210: debugfs: fix info leak in wil_write_file_wmi()") Fixes: ff974e4083341383d3dd4079e52ed30f57f376f0 ("wil6210: debugfs interface to send raw WMI command") Signed-off-by: Ammar Faizi <[email protected]> Reviewed-by: Dan Carpenter <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2022-07-27Revert "ath11k: add support for hardware rfkill for QCA6390"Kalle Valo7-206/+0
This reverts commit ec038c6127fa772d2c5604e329f22371830d5fa6. Tyler reported that on L390 Yoga Thinkpad with QCA6390 the suspend was failing because of this commit. Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.9 Link: https://bugzilla.kernel.org/show_bug.cgi?id=215881 Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.