Thread (12 messages) 12 messages, 5 authors, 2026-02-27

Re: commit 662dc80a5e86 breaks rmnet over usb

From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-02-26 01:01:57
Also in: linux-usb, lkml

On Wed, 25 Feb 2026 08:19:46 +0100 Daniele Palmas wrote:
quoted
Could you try something like:
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3a4985b582cb..6b4796fac692 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -788,6 +788,8 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
                 usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
         }

+       dev->rx_urb_size = 32768;
+  
So far userspace tools (e.g. also the most important one which is
ModemManager) rely on changing the rx_urb_size by changing the MTU: I
know this is ugly, but it is a behavior that has been there since a
lot of time, not sure how many tools based on this assumption could
break.
What's the policy in ModemManager to change the rx_urb_size?
Increase it to make sure it can hold some specific cmd / packet?

I wonder if having rx_urb_size max of (mtu, 32k) would break anything.

Since we're talking about rx buffer config the right API to configure
it is likely ethtool -G rx-buf-len :(
There's also the chance that there are modems which require a higher
rx_urb_size, so having this fixed could not work well.

Unfortunately usbnet serves many drivers, I agree with Koen that a
revert is the safest option.
Then again the usbnet driver is brittle enough as is, if it's just qmi
that needs this workaround we would be making common code less robust
for a benefit of a single "hack" (for lack of a better term)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help