kernel/git/stable/linux.git/drivers/net/usb, branch linux-5.19.y

r8152: Rate limit overflow messages

2022-10-24T07:58:16+00:00

[ Upstream commit 93e2be344a7db169b7119de21ac1bf253b8c6907 ] My system shows almost 10 million of these messages over a 24-hour period which pollutes my logs. Signed-off-by: Andrew Gaul Link: https://lore.kernel.org/r/20221002034128.2026653-1-gaul@google.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

usbnet: Fix memory leak in usbnet_disconnect()

2022-10-05T08:40:51+00:00

[ Upstream commit a43206156263fbaf1f2b7f96257441f331e91bb7 ] Currently usbnet_disconnect() unanchors and frees all deferred URBs using usb_scuttle_anchored_urbs(), which does not free urb->context, causing a memory leak as reported by syzbot. Use a usb_get_from_anchor() while loop instead, similar to what we did in commit 19cfe912c37b ("Bluetooth: btusb: Fix memory leak in play_deferred"). Also free urb->sg. Reported-and-tested-by: syzbot+dcd3e13cf4472f2e0ba1@syzkaller.appspotmail.com Fixes: 69ee472f2706 ("usbnet & cdc-ether: Autosuspend for online devices") Fixes: 638c5115a794 ("USBNET: support DMA SG") Signed-off-by: Peilin Ye Link: https://lore.kernel.org/r/20220923042551.2745-1-yepeilin.cs@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin

net: usb: qmi_wwan: Add new usb-id for Dell branded EM7455

2022-10-05T08:40:42+00:00

commit 797666cd5af041ffb66642fff62f7389f08566a2 upstream. Add support for Dell 5811e (EM7455) with USB-id 0x413c:0x81c2. Signed-off-by: Frank Wunderlich Cc: stable@vger.kernel.org Acked-by: Bjørn Mork Link: https://lore.kernel.org/r/20220926150740.6684-3-linux@fw-web.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman

r8152: add PID for the Lenovo OneLink+ Dock

2022-09-20T10:43:47+00:00

[ Upstream commit 1bd3a383075c64d638e65d263c9267b08ee7733c ] The Lenovo OneLink+ Dock contains an RTL8153 controller that behaves as a broken CDC device by default. Add the custom Lenovo PID to the r8152 driver to support it properly. Also, systems compatible with this dock provide a BIOS option to enable MAC address passthrough (as per Lenovo document "ThinkPad Docking Solutions 2017"). Add the custom PID to the MAC passthrough list too. Tested on a ThinkPad 13 1st gen with the expected results: passthrough disabled: Invalid header when reading pass-thru MAC addr passthrough enabled: Using pass-thru MAC addr XX:XX:XX:XX:XX:XX Signed-off-by: Jean-Francois Le Fillatre Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

r8152: fix the RX FIFO settings when suspending

2022-08-31T15:18:02+00:00

[ Upstream commit b75d612014447e04abdf0e37ffb8f2fd8b0b49d6 ] The RX FIFO would be changed when suspending, so the related settings have to be modified, too. Otherwise, the flow control would work abnormally. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216333 Reported-by: Mark Blakeney Fixes: cdf0b86b250f ("r8152: fix a WOL issue") Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

r8152: fix the units of some registers for RTL8156A

2022-08-31T15:18:02+00:00

[ Upstream commit 6dc4df12d741c0fe8f885778a43039e0619b9cd9 ] The units of PLA_RX_FIFO_FULL and PLA_RX_FIFO_EMPTY are 16 bytes. Fixes: 195aae321c82 ("r8152: support new chips") Signed-off-by: Hayes Wang Signed-off-by: David S. Miller Signed-off-by: Sasha Levin

net: usb: make USB_RTL8153_ECM non user configurable

2022-08-17T13:14:59+00:00

[ Upstream commit f56530dcdb0684406661ac9f1accf48319d07600 ] This refixes: commit 7da17624e7948d5d9660b910f8079d26d26ce453 nt: usb: USB_RTL8153_ECM should not default to y In general, device drivers should not be enabled by default. which basically broke the commit it claimed to fix, ie: commit 657bc1d10bfc23ac06d5d687ce45826c760744f9 r8153_ecm: avoid to be prior to r8152 driver Avoid r8153_ecm is compiled as built-in, if r8152 driver is compiled as modules. Otherwise, the r8153_ecm would be used, even though the device is supported by r8152 driver. this commit amounted to: drivers/net/usb/Kconfig: +config USB_RTL8153_ECM + tristate "RTL8153 ECM support" + depends on USB_NET_CDCETHER && (USB_RTL8152 || USB_RTL8152=n) + default y + help + This option supports ECM mode for RTL8153 ethernet adapter, when + CONFIG_USB_RTL8152 is not set, or the RTL8153 device is not + supported by r8152 driver. drivers/net/usb/Makefile: -obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o r8153_ecm.o +obj-$(CONFIG_USB_NET_CDCETHER) += cdc_ether.o +obj-$(CONFIG_USB_RTL8153_ECM) += r8153_ecm.o And as can be seen it pulls a piece of the cdc_ether driver out into a separate config option to be able to make this piece modular in case cdc_ether is builtin, while r8152 is modular. While in general, device drivers should indeed not be enabled by default: this isn't a device driver per say, but rather this is support code for the CDCETHER (ECM) driver, and should thus be enabled if it is enabled. See also email thread at: https://www.spinics.net/lists/netdev/msg767649.html In: https://www.spinics.net/lists/netdev/msg768284.html Jakub wrote: And when we say "removed" we can just hide it from what's prompted to the user (whatever such internal options are called)? I believe this way we don't bring back Marek's complaint. Side note: these incorrect defaults will result in Android 13 on 5.15 GKI kernels lacking USB_RTL8153_ECM support while having USB_NET_CDCETHER (luckily we also have USB_RTL8150 and USB_RTL8152, so it's probably only an issue for very new RTL815x hardware with no native 5.15 driver). Fixes: 7da17624e7948d5d ("nt: usb: USB_RTL8153_ECM should not default to y") Cc: Geert Uytterhoeven Cc: Greg Kroah-Hartman Cc: Hayes Wang Cc: Jakub Kicinski Signed-off-by: Maciej Żenczykowski Link: https://lore.kernel.org/r/20220730230113.4138858-1-zenczykowski@gmail.com Signed-off-by: Paolo Abeni Signed-off-by: Sasha Levin

Revert "net: usb: ax88179_178a needs FLAG_SEND_ZLP"

2022-08-17T13:13:58+00:00

commit 6fd2c17fb6e02a8c0ab51df1cfec82ce96b8e83d upstream. This reverts commit 36a15e1cb134c0395261ba1940762703f778438c. The usage of FLAG_SEND_ZLP causes problems to other firmware/hardware versions that have no issues. The FLAG_SEND_ZLP is not safe to use in this context. See: https://patchwork.ozlabs.org/project/netdev/patch/1270599787.8900.8.camel@Linuxdev4-laptop/#118378 The original problem needs another way to solve. Fixes: 36a15e1cb134 ("net: usb: ax88179_178a needs FLAG_SEND_ZLP") Cc: stable@vger.kernel.org Reported-by: Ronald Wahl Link: https://bugzilla.kernel.org/show_bug.cgi?id=216327 Link: https://bugs.archlinux.org/task/75491 Signed-off-by: Jose Alonso Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

usbnet: smsc95xx: Fix deadlock on runtime resume

2022-08-17T13:13:47+00:00

commit 7b960c967f2aa01ab8f45c5a0bd78e754cffdeee upstream. Commit 05b35e7eb9a1 ("smsc95xx: add phylib support") amended smsc95xx_resume() to call phy_init_hw(). That function waits for the device to runtime resume even though it is placed in the runtime resume path, causing a deadlock. The problem is that phy_init_hw() calls down to smsc95xx_mdiobus_read(), which never uses the _nopm variant of usbnet_read_cmd(). Commit b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") causes a similar deadlock on resume if the device was already runtime suspended when entering system sleep: That's because the commit introduced smsc95xx_reset_resume(), which calls down to smsc95xx_reset(), which neglects to use _nopm accessors. Fix by auto-detecting whether a device access is performed by the suspend/resume task_struct and use the _nopm variant if so. This works because the PM core guarantees that suspend/resume callbacks are run in task context. Stacktrace for posterity: INFO: task kworker/2:1:49 blocked for more than 122 seconds. Workqueue: usb_hub_wq hub_event schedule rpm_resume __pm_runtime_resume usb_autopm_get_interface usbnet_read_cmd __smsc95xx_read_reg __smsc95xx_phy_wait_not_busy __smsc95xx_mdio_read smsc95xx_mdiobus_read __mdiobus_read mdiobus_read smsc_phy_reset phy_init_hw smsc95xx_resume usb_resume_interface usb_resume_both usb_runtime_resume __rpm_callback rpm_callback rpm_resume __pm_runtime_resume usb_autoresume_device hub_event process_one_work Fixes: b4df480f68ae ("usbnet: smsc95xx: add reset_resume function with reset operation") Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org # v3.16+ Cc: Andre Edich Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman

usbnet: Fix linkwatch use-after-free on disconnect

2022-08-17T13:13:47+00:00

commit a69e617e533edddf3fa3123149900f36e0a6dc74 upstream. usbnet uses the work usbnet_deferred_kevent() to perform tasks which may sleep. On disconnect, completion of the work was originally awaited in ->ndo_stop(). But in 2003, that was moved to ->disconnect() by historic commit "[PATCH] USB: usbnet, prevent exotic rtnl deadlock": https://git.kernel.org/tglx/history/c/0f138bbfd83c The change was made because back then, the kernel's workqueue implementation did not allow waiting for a single work. One had to wait for completion of *all* work by calling flush_scheduled_work(), and that could deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex held in ->ndo_stop(). The commit solved one problem but created another: It causes a use-after-free in USB Ethernet drivers aqc111.c, asix_devices.c, ax88179_178a.c, ch9200.c and smsc75xx.c: * If the drivers receive a link change interrupt immediately before disconnect, they raise EVENT_LINK_RESET in their (non-sleepable) ->status() callback and schedule usbnet_deferred_kevent(). * usbnet_deferred_kevent() invokes the driver's ->link_reset() callback, which calls netif_carrier_{on,off}(). * That in turn schedules the work linkwatch_event(). Because usbnet_deferred_kevent() is awaited after unregister_netdev(), netif_carrier_{on,off}() may operate on an unregistered netdev and linkwatch_event() may run after free_netdev(), causing a use-after-free. In 2010, usbnet was changed to only wait for a single instance of usbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf ("drivers/net: don't use flush_scheduled_work()"). Unfortunately the commit neglected to move the wait back to ->ndo_stop(). Rectify that omission at long last. Reported-by: Jann Horn Link: https://lore.kernel.org/netdev/CAG48ez0MHBbENX5gCdHAUXZ7h7s20LnepBF-pa5M=7Bi-jZrEA@mail.gmail.com/ Reported-by: Oleksij Rempel Link: https://lore.kernel.org/netdev/20220315113841.GA22337@pengutronix.de/ Signed-off-by: Lukas Wunner Cc: stable@vger.kernel.org Acked-by: Oliver Neukum Link: https://lore.kernel.org/r/d1c87ebe9fc502bffcd1576e238d685ad08321e4.1655987888.git.lukas@wunner.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman