X55 modems in general. There was a lot of discussion about future
modems using PCIe instead of USB etc. I'd appreciate any info you have
on relative performance, quirks, firmware workarounds etc. If you are
allowed to share any of it..
Acked-by: Bjørn Mork"
> please find below usb-de
Adam Bennett writes:
> I've been messing around with a Raspberry Pi Zero, in its ethernet
> gadget mode. This possible bug report is not against the Pi Zero
> linux kernel, but rather the host computer's linux kernel. I've been
> able to reproduce the same host computer issue with my normal lap
Aaron Thompson writes:
> I have a Moschip 7703 USB to single serial port adapter that I'm not
> using primarily because it doesn't have an in-tree driver, so I'd be
> happy to send it to anyone who would like to add support for it. It
> looks like it should be easy to add to the existing mos7720
Jakub Kicinski writes:
> On Wed, 18 Sep 2019 14:17:38 +0200, Bjørn Mork wrote:
>> Endpoints with zero wMaxPacketSize are not usable for transferring
>> data. Ignore such endpoints when looking for valid in, out and
>> status pipes, to make the drivers more robus
Greg KH writes:
>> >> [ 44.059958] qmi_wwan 1-1:1.3 wwan0: unregister 'qmi_wwan'
>> >> usb-ci_hdrc.1-1, We
..
>> That was always my thought until I tried kernel 5.1 under the same
>> platform (nothing changed except the kernel version), the kernel 5.1
>> can connect to the 4G modem, I could no
divisors in many usbnet minidrivers. Avoiding zero is therefore
critical.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/usbnet.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
index 58952a79b05f..dbea2136d901 100644
--- a/drivers/net
divide-by-zero bug.
Reported-by: syzbot+ce366e2b8296e25d8...@syzkaller.appspotmail.com
Signed-off-by: Bjørn Mork
---
#syz test: https://github.com/google/kasan.git f0df5c1b
drivers/net/usb/cdc_ncm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb
firmware. The ZTE example is most likely also part of a larger
family of devices/firmwares.
Suggested-by: Lars Melin
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ether.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net
writes:
>> > What better suggestion do folks have, instead of using
>> USB_REQ_SET_ADDRESS?
>>
>> The spec is clear: wIndex is supposed to be 'NCM Communications Interface'.
>> That's how you address a specific NCM function (a USB device can have more
>> than one...), and that's what you'll see
writes:
> What better suggestion do folks have, instead of using USB_REQ_SET_ADDRESS?
The spec is clear: wIndex is supposed to be 'NCM Communications
Interface'. That's how you address a specific NCM function (a USB
device can have more than one...), and that's what you'll see in all the
other
writes:
> +static int cdc_ncm_get_ethernet_address(struct usbnet *dev,
> + struct cdc_ncm_ctx *ctx)
Is this function called anywhere? Shouldn't it replace the
usbnet_get_ethernet_addr() call in cdc_ncm_bind_common()?
But do note that cdc_ncm_bind_common() i
writes:
> + if (strstr(dev->udev->product, "D6000")) {
Huh? Can you please test that on all USB devices ever made?
Bjørn
writes:
> +static int cdc_ncm_resume (struct usb_interface *intf)
> +{
> + struct usbnet *dev = usb_get_intfdata(intf);
> + struct cdc_ncm_ctx *ctx = (struct cdc_ncm_ctx *)dev->data[0];
> + int ret;
> +
> + ret = usbnet_resume(intf);
> + if (ret != 0)
> + goto erro
writes:
> @@ -930,11 +931,18 @@ int cdc_ncm_bind_common(struct usbnet *dev, struct
> usb_interface *intf, u8 data_
> usb_set_intfdata(ctx->control, dev);
>
> if (ctx->ether_desc) {
> + struct sockaddr sa;
> +
> temp = usbnet_get_ethernet_addr(dev,
> ctx->
writes:
> This change moves ACPI functionality out of the Realtek r8152 driver to
> its own source and header file, making it available to other drivers as
> needed now and into the future. At the time this ACPI snippet was
> introduced in 2016, only the Realtek driver made use of it in support
writes:
> This change moves ACPI functionality out of the Realtek r8152 driver to
> its own source and header file, making it available to other drivers as
> needed now and into the future. At the time this ACPI snippet was
> introduced in 2016, only the Realtek driver made use of it in support
Oliver Neukum writes:
> + wait_event(desc->wait,
> + /*
> + * needs both flags. We cannot do with one
> + * because resetting it would cause a race
> + * with write() yet we need to signal
> +
Oliver Neukum writes:
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> index 1656f5155ab8..a341081a5f47 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -588,14 +588,24 @@ static int wdm_flush(struct file *file, fl_owner_t id)
> {
>
xes: e4bf63482c30 ("qmi_wwan: Add quirk for Quectel dynamic config")
Signed-off-by: Bjørn Mork
---
The bug was introduced in v5.2-rc1 but has been backported to stable kernels.
So this fix also needs to go into stable.
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+
xPS= 512 Ivl=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
Cc: sta...@vger.kernel.org
Signed-off-by: Bjørn Mork
---
drivers/usb/serial/option.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 11b21d9410f3..02ee5b707de2 100
Peter Schüller writes:
> [corrected email of Kai-Heng Feng]
>
> Am Mo., 18. März 2019 um 15:39 Uhr schrieb Dan Williams :
>> [removing netdev list...]
>>
>> With the modem plugged in, could you grab the output of:
>>
>> lsusb -v -d 12d1:14dc
>
> The output is on STDERR
>
> Couldn't open device, s
like it's time to consider applying this unconditionally
to all devices. Feel free to propose something like that the next time
this issue comes up.
Acked-by: Bjørn Mork
This function is unreadable enough without indenting mismatches
and unnecessary line breaks.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ether.c | 26 +++---
1 file changed, 11 insertions(+), 15 deletions(-)
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb
Frédéric Parrenin writes:
> Le 26/11/2018 à 15:21, mario.limoncie...@dell.com a écrit :
>>
>> Any feedback from testing with this debugging patch to identify what's
>> happening?
>
> This is super strange, but Mac address pass-through is now working in
> my configuration, although I did not chan
writes:
> On Nov 22, 2018 03:41, Frédéric Parrenin
> wrote:
>>
>> A guy answered on the amazon page that he has Mac pass-through working
>> on windows 10 with this exact same dock station.
>> So it really seems to be a linux-only problem.
>
> Well thanks for checking further. This is quite surpr
Greg KH writes:
> I do not see any USB networking device here at all.
No, It wasn't easy to see. But it's there both with and without the
feature enabled:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
| Port 4: Dev 10, If 0, Class=Hub, Driver=hub/7p, 5000M
|__ P
Ben Dooks writes:
> Add a configuration option for the default state of turbo mode
> on the smsc95xx networking driver. Some systems it is better
> to default this to off as it causes significant increases in
> soft-irq load.
So there is already a module option allowing you to change this, usin
Ben Dooks writes:
> +static inline struct qmi_wwan_state *usbnet_to_qmi(struct usbnet *usb)
> +{
> + return (void *) &usb->data;
> +}
checkpatch doesn't like this, and it is also inconsistent with the
coding style elsewhere in the driver.
CHECK: No space is necessary after a cast
#30: FILE
Igor Russkikh writes:
> +struct aq_tx_packet_desc {
> + struct {
> + u32 length:21;
> + u32 checksum:7;
> + u32 drop_padding:1;
> + u32 vlan_tag:1;
> + u32 cphi:1;
> + u32 dicf:1;
> + };
> + struct {
> +
Igor Russkikh writes:
> From: Dmitry Bezrukov
>
> Signed-off-by: Dmitry Bezrukov
> Signed-off-by: Igor Russkikh
> ---
You'd want some description here.
Bjørn
Igor Russkikh writes:
>> +static const struct driver_info aqc111_info = {
> + .description= "Aquantia AQtion USB to 5GbE Controller",
> +};
> +
> +#define AQC111_USB_ETH_DEV(vid, pid, table) \
> + .match_flags = USB_DEVICE_ID_MATCH_DEVICE | \
> + USB_DEVICE_ID_MATC
Igor Russkikh writes:
> +static int __aqc111_read_cmd(struct usbnet *dev, u8 cmd, u16 value,
> + u16 index, u16 size, void *data, int nopm)
> +{
> + int ret;
> + int (*fn)(struct usbnet *dev, u8 cmd, u8 reqtype, u16 value,
> + u16 index, void *data,
Oliver Neukum writes:
> On Fr, 2018-10-05 at 10:24 +, Igor Russkikh wrote:
>> From: Dmitry Bezrukov
>>
>> Reset, stop callbacks, driver unbind callback.
>> More register defines required for these callbacks.
>>
>> Signed-off-by: Dmitry Bezrukov
>> Signed-off-by: Igor Russkikh
>> ---
>>
easier to spot mismatches
between the firmware data and the real world.
Signed-off-by: Bjørn Mork
---
v4: remove unrelated ABI doc changes, thanks to Alan Stern for noticing
v3: resurrect missing hunk, as pointed out by the kbuild test robot
v2: Sorry, forgot to rebase the old branch before sendin
Alan Stern writes:
>> diff --git a/Documentation/ABI/testing/sysfs-bus-usb
>> b/Documentation/ABI/testing/sysfs-bus-usb
>> index 08d456e07b53..8f394c976fee 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-usb
>> +++ b/Documentation/ABI/testing/sysfs-bus-usb
>> @@ -173,14 +173,14 @@ Descriptio
easier to spot mismatches
between the firmware data and the real world.
Signed-off-by: Bjørn Mork
---
v3: resurrect missing hunk, as pointed out by the kbuild test robot
v2: Sorry, forgot to rebase the old branch before sending v1
This patch got stuck in one of my debugging branches. It proved v
easier to spot mismatches
between the firmware data and the real world.
Signed-off-by: Bjørn Mork
---
v2: Sorry, forgot to rebase the old branch before sending v1
This patch got stuck in one of my debugging branches. It proved very
useful to me while trying to figure out why the "peer"
mismatches
between the firmware data and the real world.
Signed-off-by: Bjørn Mork
---
This patch got stuck in one of my debugging branches. It proved very
useful to me while trying to figure out why the "peer" link was useless
on a specific host. And if it was useful to me once, then maybe i
method fails when the modems are forced to
USB2 mode by the modem firmware.
Fix by unconditionally enabling the DTR quirk for the
affected device IDs.
Reported-by: Fred Veldini
Reported-by: Deshu Wen
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 14 +++---
1 file changed, 7
Dan Williams writes:
> The fact that the firmware implementation has the ability to change the
> endpoints is unrelated to Kristian's case, and that alone is
> justification for this to be quirked in the driver. People other than
> Kristian will undoubtedly use the functionality, on platforms le
Aleksander Morgado writes:
> Being a Qualcomm based chipset, I believe qcserial would be more appropriate.
Plenty of Qualcomm devices are handled by option. IMHO, there is no
point in adding device specific interface matching to qcserial, unless
it is a reusable pattern like the ones we have the
Oliver Neukum writes:
> On Di, 2018-06-26 at 09:40 +0200, Bjørn Mork wrote:
>> This code can make Linux default to a MBIM configuration if the MBIM
>> function uses the first interface in that configuration, even if this
>> configuration is not the first one. Availabili
Aleksander Morgado writes:
> On Tue, Jun 26, 2018 at 8:09 AM, Johan Hovold wrote:
>> On Sat, Jun 23, 2018 at 11:24:08PM +0200, Aleksander Morgado wrote:
>>> This module exposes two USB configurations: a QMI+AT capable setup on
>>> USB config #1 and a MBIM capable setup on USB config #2.
>>>
>>>
Johan Hovold writes:
> On Sat, Jun 23, 2018 at 11:24:08PM +0200, Aleksander Morgado wrote:
>> This module exposes two USB configurations: a QMI+AT capable setup on
>> USB config #1 and a MBIM capable setup on USB config #2.
>>
>> By default the kernel will choose the MBIM capable configuration as
Sebastian Andrzej Siewior writes:
> On 2018-06-12 12:43:01 [-0400], Alan Stern wrote:
>> On Tue, 12 Jun 2018, Sebastian Andrzej Siewior wrote:
>>
>> > In the code path
>> > __usb_hcd_giveback_urb()
>> > -> wdm_in_callback()
>> >-> service_outstanding_interrupt()
>> >
>> > The function s
Josh Hill writes:
> Add support for Netgear Aircard 779S
>
> Signed-off-by: Josh Hill
Acked-by: Bjørn Mork
Please queue this for stable too. Thanks.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@v
: add QMI_QUIRK_SET_DTR for Telit PID 0x1201")
Initial testing on an older SIM7100 modem shows no immediate side
effects.
Reported-by: Sebastian Sjoholm
Cc: Reinhard Speyerer
Signed-off-by: Bjørn Mork
---
I propose this for net-next for now to get some extra testing
exposure before going into sta
MBIM, without the device ID changing either.
Fix by requiring the vendor-specific class for interface number
based matching. Functions of other classes can and should use
class based matching instead.
Fixes: 03304bcb5ec4 ("net: qmi_wwan: use fixed interface number matching")
Signed-off
Johan Hovold writes:
> On Thu, Apr 26, 2018 at 02:48:54PM +0700, Lars Melin wrote:
>> On 4/26/2018 14:09, Johan Hovold wrote:
>> > On Thu, Apr 26, 2018 at 02:28:31PM +0800, SZ Lin (林上智) wrote:
>> >> This patch adds support for ublox R410M PID 0x90b2 USB modem to option
>> >> driver, this module su
"SZ Lin (林上智)" writes:
> This patch adds support for PID 0x90b2 of ublox R410M.
Acked-by: Bjørn Mork
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
one)
> E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
> E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=125us
>
> Tested on openwrt distribution
>
> Signed-off-by: Pawel Dembicki
Acked-by: Bjørn Mork
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Bassem Boubaker writes:
> +#define GEMALTO_VENDOR_ID0x1e2d
This is defined as CINTERION_VENDOR_ID in drivers/usb/serial/option.c.
I have no idea which defintion is most correct, but I believe the macros
should be kept identical whatever you decide. Anything else is just
unnecessarily confus
"Rafael J. Wysocki" writes:
> On 2/4/2018 9:28 PM, Bjørn Mork wrote:
>
>> But I do wonder if the attached (completely untested!!) patch makes
>> things any better?
>
> I don't think so, the macro is needed too.
Doh! Obviously. Don't know how I m
("ACPI / EC: Use busy polling mode when GPE is not enabled")
Fixes: c3a696b6e8f8 ("ACPI / EC: Use busy polling mode when GPE is not enabled")
Signed-off-by: Bjørn Mork
---
drivers/acpi/ec.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/ac
Johan Hovold writes:
> IIRC we have already started reusing entries, but the names have not
> always been made generic in the process. I think Bjørn may have proposed
> a generic naming scheme at some point, but that essentially just meant
> we encoded the two masks in the name.
Maybe. I dont' r
c6, 0x920d, 5)},
> + {QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
> {QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
> {QMI_FIXED_INTF(0x12d1, 0x140c, 1)},/* Huawei E173 */
> {QMI_FIXED_INTF(0x12d1, 0x14ac, 1)},/* Huawei E1820 */
Perfect. Thanks
Acked-by: Bjø
"SZ Lin (林上智)" writes:
>> Johan Hovold writes:
>>
>> >> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = {
>> >> + .reserved = BIT(0) | BIT(1) | BIT(4), };
>> >
>> > Do you really need to blacklist the first interface?
>>
>> Good question. Interface #0 does look a lot like
Johan Hovold writes:
>> +static const struct option_blacklist_info yuga_clm920_nc5_blacklist = {
>> +.reserved = BIT(0) | BIT(1) | BIT(4),
>> +};
>
> Do you really need to blacklist the first interface?
Good question. Interface #0 does look a lot like a Qualcomm DM/DIAG
function, based on tw
Vamsi Samavedam writes:
> On Thu, Dec 14, 2017 at 07:55:50PM +0100, Bjørn Mork wrote:
>> It has been reported that the dummy byte we add to avoid
>> ZLPs can be forwarded by the modem to the PGW/GGSN, and that
>> some operators will drop the connection if this happens.
latter
assumption failed. Let's test out the first.
Signed-off-by: Bjørn Mork
---
I am a bit worried about the effect of this change on all the
devices I can't test myself. But trying it is the only way we
can ever find out
drivers/net/usb/qmi_wwan.c | 4 ++--
1 file changed, 2
Reinhard Speyerer writes:
> Sierra Wireless EM7565 devices use the DEVICE_SWI layout for their
> serial ports
>
> T: Bus=01 Lev=03 Prnt=29 Port=01 Cnt=02 Dev#= 31 Spd=480 MxCh= 0
> D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
> P: Vendor=1199 ProdID=9091 Rev= 0.06
> S: Manufac
100V LTE) */
> {QMI_FIXED_INTF(0x1bbb, 0x0203, 2)},/* Alcatel L800MA */
> {QMI_FIXED_INTF(0x2357, 0x0201, 4)},/* TP-LINK HSUPA Modem MA180 */
Looks good except for the duplicate 'From' line. Drop that and you can
add
Acked-by: Bjørn Mork
--
To unsubscribe from this list: send the lin
David Miller writes:
> From: Bjørn Mork
> Date: Wed, 6 Dec 2017 20:21:24 +0100
>
>> The qmi_wwan minidriver support a 'raw-ip' mode where frames are
>> received without any ethernet header. This causes alignment issues
>> because the skbs allocated by u
d using a per-device flag, since the same
minidriver also supports 'ethernet' mode.
Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Reported-and-tested-by: Jay Foster
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 ++
drivers/net/usb/us
-off-by: Sebastian Sjoholm
Perfect. Thanks.
Acked-by: Bjørn Mork
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Shrirang Bagul writes:
> Dell Wireless 5819/5818 devices are re-branded Sierra Wireless MC74
> series modems which will by default boot with vid 0x413c and pid's
> 0x81cf, 0x81d0, 0x81d1,0x81d2. Along with qcserial, these modems support
> qmi_wwan on the usb interface #12.
NAK,
Interace #12 is
On November 20, 2017 5:19:21 AM GMT+01:00, ssjoh...@mac.com wrote:
>From: ssjoholm
>
>Signed-off-by: ssjoholm
>
>Quectel BG96 is an Qualcomm MDM9206 based IoT modem, supporting both
>CAT-M and NB-IoT. Tested hardware is BG96 mounted on Quectel
>development board (EVB).
>The USB id is added to q
constant by converting
the constant to LE.
Reported-by: Ben Hutchings
Fixes: 2b02c20ce0c2 ("cdc_ncm: Set NTB format again after altsetting switch for
Huawei devices")
Cc: Enrico Mioso
Cc: Christian Panton
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 4 ++--
1 file changed, 2
Ben Hutchings writes:
> On Tue, 2017-07-11 at 17:21 +0200, Enrico Mioso wrote:
>> From: Enrico Mioso
>>
>> commit 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f upstream.
> [...]
>> --- a/drivers/net/usb/cdc_ncm.c
>> +++ b/drivers/net/usb/cdc_ncm.c
>> @@ -724,8 +724,10 @@ int cdc_ncm_bind_common(struc
On November 15, 2017 12:42:17 AM GMT+01:00, Alexander Mikhalevich
wrote:
>Hi,
>I've recently bought Thinkpad x270 with Fibocom-L831EU WWAN module
>which is MBIM device. If I try to use it on my Gentoo Linux (kernel
>4.12.12, libmbim 1.14) it doesn't work.
>The symptoms are the same as it was de
erface is configured as-such, it seems certain
> parts of the network stack expects a "good" value in skb->mac_header.
Thanks. Yes, I see that the tun driver also does this.
Acked-by: Bjørn Mork
And his should probably go to stable as well? with a
Fixes: 32f7adf633b9 ("net
Setting dev->hard_mtu to 0 will cause a divide error in
usbnet_probe. Protect against devices with bogus CDC Ethernet
functional descriptors by ignoring a zero wMaxSegmentSize.
Signed-off-by: Bjørn Mork
---
I believe the problem found by syzcaller in qmi_wwan also applies
to cdc_ether.
based WWAN
devices")
Reported-by: Andrey Konovalov
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8c3733608271..a4f229edcceb 100644
--- a/drivers/net/usb/
Andrey Konovalov writes:
> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.
Thanks. It would have helped a lot of you said *what* you were fuzzing,
though But based on where the bug is, I assume it is USB
descriptors?
> On commit 39dae59d66acd86d1de24294bd2f3
Juan Zea writes:
> Having a look at the code of the VHCI driver at
> https://github.com/torvalds/linux/tree/master/drivers/usb/usbip , I
> found these two parameters: USBIP_VHCI_HC_PORTS and USBIP_VHCI_NR_HCS
>
> I've compiled VHCI driver from latest source above, altering both
> parameters to ge
"Gustavo A. R. Silva" writes:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> Notice that in this particular case I replaced "...drop on through"
> comments with a proper "fall through" comment on its own line, which
> is what G
Gal Shalif writes:
> Bjoren> You can always unbind the driver, right? And usb_modeswitch will
> even do it for you.
> I'm not a USB mode switch expert, so please explain what is the mode switch
> file that you suggest.
>
> As I already said before - my kernel configuration will not allow a USB
>
Oliver Neukum writes:
> Am Dienstag, den 24.10.2017, 23:17 +0300 schrieb Gal Shalif:
>> The option driver is compiled as a module.
>> The option driver patch, and other related patches are listed within
>> my previous email:
>
> Hi,
>
> but you are adding the device unconditionally to the HID blac
Shrirang Bagul writes:
> On Tue, 2017-10-03 at 15:37 +0200, Johan Hovold wrote:
>
>> Don't you want to add these to qmi_wwan as well?
>
> I haven't tested these devices with qmi_wwan. Perhaps a separate patch once
> it's
> verified.
Please do, if you can. I realize that QMI isn't a default conf
such device
until we've actually seen one.
This is just my opinion, and probably full of bogus assumptions as
usual. I was sort of hoping that some expert would speak up so I didn't
have to :-)
But FWIW:
Reviewed-by: Bjørn Mork
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
unexpected behaviour, hoping that it attracts attention from firmware
developers.
Cc:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100938
Reported-and-tested-by: Christian Ehrig
Reported-and-tested-by: Patrick Chilton
Reported-and-tested-by: Andreas Böhler
Signed-off-by: Bjørn Mork
---
The
Andreas Böhler writes:
> As promised I made the new module the default and tested it for a few
> days. Although the error messages persist, I did not notice any negative
> side effects. In fact, it also fixes a problem where mbim-proxy was at
> 100% load.
>
> Two other users also reported success
Douglas Anderson writes:
> Every once in a while when my system is under a bit of stress I see
> some spammy messages show up in my logs that say:
>
> kevent X may have been dropped
>
> As far as I can tell these messages aren't terribly useful.
I agree, FWIW. These messages just confuse users
Douglas Anderson writes:
> If rx_submit() returns an error code then nobody calls usb_free_urb().
> That means it's leaked.
Nope. rx_submit() will call usb_free_urb() before returning an error:
static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
..
if (!skb) {
Andreas Böhler writes:
> On 19/09/17 14:25, Bjørn Mork wrote:
>> Bjørn Mork writes:
>>
>> What happens if you kill the mbim-proxy process? Are you then able to
>> use the modem again without resetting it?
>
> I was unable to test that: It can only be killed us
Bjørn Mork writes:
> Thanks a lot. These are very useful. The thing is that I really cannot
> see anything going wrong there. The "failed" capture just ends with a
> sequence of successful MBIM indications being read from the firmware.
>
> So whatever goes wrong look
Andreas Böhler writes:
> On 18/09/17 22:18, Bjørn Mork wrote:
>> Andreas Böhler writes:
>>>
>>> I can also provide you with Wireshark USB traces, if that helps?
>>
>> It might help. We are obviously interacting badly with the firmware.
>>
Andreas Böhler writes:
> Unfortunately, it doesn't change anything. I applied the patch,
> recompiled the kernel (it updated to 4.13.2 at the same time), rebooted
> and upon connecting, I can see the 'cdc_mbim 1-6:1.0: nonzero urb status
> received: -EPIPE' message again.
Thanks for testing. The
driver internal error state.
Fixes: c1da59dad0eb ("cdc-wdm: Clear read pipeline in case of error")
Signed-off-by: Bjørn Mork
---
drivers/usb/class/cdc-wdm.c | 39 ++-
1 file changed, 10 insertions(+), 29 deletions(-)
diff --git a/drivers/usb/class/cd
Anna-Maria Gleixner writes:
> From: Thomas Gleixner
>
> The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
> softirq context. This can be also achieved without the tasklet but with
> CLOCK_MONOTONIC_SOFT as hrtimer base.
>
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Ann
=0ms
E: Ad=06(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Bjørn Mork
---
Johan Hovold writes:
> Do you want to submit a patch or should I do it?
Well, I can save you that job if this is fine with you. Feel
free to add a stable cc if you think it is appropriate. I am not
sure...
Bj
Johan Hovold writes:
> On Mon, Aug 28, 2017 at 04:32:53PM +0200, Maciej S. Szmigiero wrote:
>
>> Also, three other D-Link modems few lines above are using the same
>> USB_DEVICE_AND_INTERFACE_INFO() selectors.
>
> Yeah, I noticed those, and I'm not sure why they're not using
> class-matching only
On August 8, 2017 9:22:29 PM CEST, Giuseppe Lippolis
wrote:
>> But we already have many Sierra devices with 2 QMI interfaces (the
>3rd one
>> is documented and verified non-functional for unknown reasons). And
>these
>> tend to come with multiple OEM device IDs. So a whitelist method
>could
>>
disconnect+0x87/0xc0 [qmi_wwan]
? usb_unbind_interface+0x71/0x270 [usbcore]
? device_release_driver_internal+0x154/0x210
Reported-and-tested-by: Nathaniel Roach
Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
Cc: Daniele Palmas
Signed-off-by: Bjørn Mork
Johan Hovold writes:
> On Mon, Aug 07, 2017 at 04:22:27PM +0200, Oleg Kokorin wrote:
>> From 336f8adb0292a25ea41f0515a80850031f814b9b Mon Sep 17 00:00:00 2001
>> From: Oleg Kokorin
>> Date: Mon, 7 Aug 2017 15:35:53 +0200
>> Subject: [PATCH] append Qualcomm GOBI 2K chipset ID for Panasonic CF-U1
"Giuseppe Lippolis" writes:
> Hi all,
> I'm working to port OpenWRT/LEDE on a new router with embedded usb LTE
> modem.
> The modem have 3 qmi_wwan interfaces and 2 option.
>
> I would like to prepare the patch, but before I would like to know if using
> the QMI_FIXED_INTF macro is the best way t
Johan Hovold writes:
> On Tue, Jul 11, 2017 at 08:52:37AM +0200, Anatolij Gustschin wrote:
>
>> For devices with connected EEPROM some modes (including UART) are
>> configurable in the EEPROM. For devices without EEPROM the default
>> mode is always UART, but FIFO-, Bitbang- and MPSSE-mode can be
Oliver Neukum writes:
> Am Dienstag, den 11.07.2017, 17:21 +0200 schrieb Enrico Mioso:
>> Some firmwares in Huawei E3372H devices have been observed to switch back
>> to NTB 32-bit format after altsetting switch.
>> This patch implements a driver flag to check for the device settings and
>> set NT
v to have it applied, but I guess you
know that :-)
Feel free to add
Reviewed-by: Bjørn Mork
when you do so, if you want.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[CCing Enrico]
Christian Panton writes:
> Found a solution.
>
>>> I have two mobile broadband Huawei E3372h devices, one with firmware
>>> 21.200.07.01.26 (aka the 200-version) and one with firmware
>>> 21.318.01.00.541 (aka the 318-version).
>>>
>>> Whereas the 200-version works perfectly with
1 - 100 of 1116 matches
Mail list logo
