[PATCH v2] USB: serial: option: Add support for Quectel EP06

->v2: * Updated commit prefix (thanks Johan Hovold) * Updated commit message slightly. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/usb/serial/option.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial

Re: [PATCH] option: Add support for Quectel EP06

Hi Johan, On Wed, Jan 31, 2018 at 7:38 AM, Johan Hovold wrote: > This will probably have to do for now, but we already have another > blacklist struct with the same content which we could rename and > reuse. I noticed the same, but wasn't quite sure about the policy on

[PATCH] option: Add support for Quectel EP06

The Quectel EP06 is a Cat. 6 LTE modem, and the interface mapping is as follows: 0: Diag 1: NMEA 2: AT 3: Modem Interface 4 is QMI and interface 5 is ADB, so they are blacklisted. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/usb/serial/option.c | 7 +++

Re: [PATCH net] qmi_wwan: Add missing skb_reset_mac_header-call

Hei, On Tue, Nov 7, 2017 at 2:02 PM, Bjørn Mork wrote: > And his should probably go to stable as well? with a > > Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode") Yes, I forgot to add the fixes-tag + comment about stable. Should I submit a v2? -Kristian -- To

[PATCH net] qmi_wwan: Add missing skb_reset_mac_header-call

04.031034] [ 304.032805] ---[ end trace b778c482b3f0bda9 ]--- [ 304.041384] Kernel panic - not syncing: Fatal exception in interrupt [ 304.051975] Rebooting in 3 seconds.. While the oops is for a 4.9-kernel, I was able to trigger the same oops with net-next as of yesterday. Signed-off-by: Kris

Re: Random xHCI HC died on device disconnect

Hi, On Wed, Oct 4, 2017 at 12:16 PM, Mathias Nyman wrote: > This is the xhci->cmd_timer (delayed work) that has a five second timeout > for the currently processing command on the command ring. > When triggered it will abort the current command by stopping the

Re: Random xHCI HC died on device disconnect

On Tue, Oct 3, 2017 at 4:51 PM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Disabling the timer caused a different error to be triggered. Instead > of "HC died...", I now get the following message looping over and > over: > > [16870.871935] qmi_wwa

Re: Random xHCI HC died on device disconnect

Hi, On Tue, Oct 3, 2017 at 11:16 AM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Messing with the driver is no problem :) Thanks for this pointer, I am > testing stopping the timer now and will let you know how it goes. Disabling the timer caused a different error to

Re: Random xHCI HC died on device disconnect

Hi Mathias, Thank you very much for your reply. On Tue, Oct 3, 2017 at 10:28 AM, Mathias Nyman wrote: > For temporary workarounds: > if xhci is a module then unload and reload in using modprobe > > Or then unbind/rebind the driver and device. > on a Intel PCI

Random xHCI HC died on device disconnect

Hello, I am currently working on a custom Armada 385-based board running kernel 4.9.52. I have a USB 2.0 LTE modem connected to USB 3.0, and the modem sometimes crashes due to various internal (on the modem) reasons. The board supports restarting the USB-ports using GPIOs, and at random points

[PATH net v2] cdc_ether: Fix handling connection notification

andling") Reported-by: Henning Schild <henning.sch...@siemens.com> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.c | 38 +++--- 1 file changed, 31 insertions(+), 7 deletions(-) diff --git a/drivers/ne

Re: [PATCH net] cdc_ether: Fix handling connection notification

On Wed, Nov 30, 2016 at 10:51 PM, Bjørn Mork <bj...@mork.no> wrote: > Kristian Evensen <kristian.even...@gmail.com> writes: > >> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb) >> +{ >> + struct usb_cdc_notification *event; >> + >&

[PATCH net] cdc_ether: Fix handling connection notification

"cdc_ether: Improve ZTE MF823/831/910 handling") Reported-by: Henning Schild <henning.sch...@siemens.com> Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.c | 38 +++--- 1 file changed, 31 insertion

Re: cdc_ether flooding kernel logs since bfe9b9d2d

Hi, On Wed, Nov 30, 2016 at 4:17 PM, Oliver Neukum <oneu...@suse.com> wrote: > On Tue, 2016-11-29 at 14:41 +0100, Kristian Evensen wrote: >> I don't know which of the two behaviors (if any) are "correct" or what >> the best way to solve this problem is. One option

Re: cdc_ether flooding kernel logs since bfe9b9d2d

Hi, On Tue, Nov 29, 2016 at 11:27 AM, Henning Schild wrote: > commit bfe9b9d2d introduced a workaround for link status detection. > That workaround seems to cause a tight loop of usbnet_cdc_status being > called all the time, which in turn prints > "kevent 11 may have

[PATCH net-next v4] cdc_ether: Improve ZTE MF823/831/910 handling

PIDs/MAC addresses. In other words, it seems to be the default behavior of ZTE CDC Ether devices (thanks Lars Melin). Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> Acked-by: Oliver Neukum <oneu...@suse.com> --- drivers/net/usb/cdc_ether.c | 51 +++

[PATCH net-next v3] cdc_ether: Improve ZTE MF823/831/910 handling

evices (thanks Lars Melin). Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.c | 54 + 1 file changed, 54 insertions(+) diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c index 7cba2c3..87

Re: [PATCH net-next v2] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, Jul 19, 2016 at 2:33 PM, Oliver Neukum <oli...@neukum.org> wrote: > On Tue, 2016-07-19 at 13:49 +0200, Kristian Evensen wrote: >> @@ -428,10 +434,47 @@ int usbnet_cdc_bind(struct usbnet *dev, struct >> usb_interface *intf) >>

[PATCH net-next v2] cdc_ether: Improve ZTE MF823/831/910 handling

try, as the bogus MAC have been seen on devices with several different PIDs/MAC addresses. In other words, it seems to be the default behavior of ZTE CDC Ether devices (thanks Lars Melin). Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_eth

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

Hi Lars, On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin <lars...@gmail.com> wrote: > On 2016-07-19 13:40, Kristian Evensen wrote: > >> I guess I can match on the VID/PID in usbnet, but won't it be cleaner >> to add a new bind() function (in cdc_ether) which matches the two

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Tue, Jul 19, 2016 at 8:20 AM, Oliver Neukum wrote: >> I had a look at some other drivers, and I think we need to be very >> careful about making setting a random MAC too generic. For example, we >> might be unlucky and break the possibly_iphdr()-code/assumption in >>

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote: >> Ok, sounds good. So far, I have only seen the random MAC issue with >> the three previously mentioned devices, but who knows how many else is >> out there with the same error ... I don't think it should be in the >> core

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, Jul 18, 2016 at 4:14 PM, Oliver Neukum wrote: >> Ok, sounds good. So far, I have only seen the random MAC issue with >> the three previously mentioned devices, but who knows how many else is >> out there with the same error ... I don't think it should be in the >> core

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

On Mon, Jul 18, 2016 at 3:50 PM, Oliver Neukum wrote: > No, you misunderstand me. I don't want quirks if we can avoid it. > But if you need to do this for rndis_host and cdc_ether and maybe other > drivers you should not be touching drivers. This belongs into the core > ethernet

Re: [PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

Hi, On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum <oneu...@suse.com> wrote: > On Mon, 2016-07-18 at 14:24 +0200, Kristian Evensen wrote: >> The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to >> determine which type of device to export. In addition,

[PATCH net-next] cdc_ether: Improve ZTE MF823/831/910 handling

operational state and I can receive/sent traffic without problems. I also tested with some other cdc_ether devices I have and did not find any problems/regressions caused by the two general changes. Signed-off-by: Kristian Evensen <kristian.even...@gmail.com> --- drivers/net/usb/cdc_ether.

[PATCH net-next] rndis_host: Set valid random MAC on buggy devices

From: Kristian Evensen <kristian.even...@gmail.com> Some devices of the same type all export the same, random MAC address. This behavior has been seen on the ZTE MF910, MF823 and MF831, and there are probably more devices out there. Fix this by generating a valid random MAC address if w

Re: [PATCH] rndis_host: Set random MAC for ZTE MF910

On Thu, Jul 14, 2016 at 9:54 AM, Kristian Evensen <kristian.even...@gmail.com> wrote: > Hi Bjørn, > > On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork <bj...@mork.no> wrote: >> >> Or how about the more generic?: >> >> if (bp[0] &

Re: [PATCH] rndis_host: Set random MAC for ZTE MF910

Hi Bjørn, On Thu, Jul 14, 2016 at 12:23 AM, Bjørn Mork wrote: > > Or how about the more generic?: > > if (bp[0] & 0x02) > eth_hw_addr_random(net); > else > ether_addr_copy(net->dev_addr, bp); > > That would catch similar screwups

[PATCH] rndis_host: Set random MAC for ZTE MF910

From: Kristian Evensen <kristian.even...@gmail.com> All ZTE MF910 mifis, at least on some revisions, export the same MAC address (36:4b:50:b7:ef:da). Check for this MAC address and set a random MAC if detected. Also, changed the memcpy() to ether_addr_copy(), as pointed out by chec

[PATCH] usb: hid: Add new PID for Microchip Pick16F1454

From: Kristian Evensen <kristian.even...@gmail.com> There seems to be a new version of the Microchip Pick16F1454 with a different PID (0xf2f7). This device should also be ignored by the HID driver. The PID was observed with the second version of the Yepkit Ykush USB hub. Signed-off-by: Kr

[PATCH] usb: hid: Do not bind to Microchip Pick16F1454

-by: Kristian Evensen kristian.even...@gmail.com --- drivers/hid/hid-core.c | 1 + drivers/hid/hid-ids.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c index 8b63879..77afffc 100644 --- a/drivers/hid/hid-core.c +++ b/drivers/hid/hid-core.c @@ -2328,6

Re: [PATCH] usb: misc: Driver for Yepkit YKUSH switchable hub

Hi, On Mon, Jan 19, 2015 at 10:38 PM, Greg KH g...@kroah.com wrote: That's great, and the hid parts of the patch makes sense, keeping the HID driver from binding to it, but for the rest, shouldn't that just be a simple userspace program instead? We don't like to add kernel drivers that can

[PATCH] qmi_wwan: Set random MAC on devices with buggy fw

From: Kristian Evensen kristian.even...@gmail.com Some buggy firmwares export an incorrect MAC address (00:a0:c6:00:00:00). This makes for example checking devices for random MAC addresses tricky, and you might end up with multiple network interfaces with the same address. This patch tries

Re: ar71xx: Problems with USB WIFI dongles

Hi all, On Sat, Aug 9, 2014 at 12:03 PM, Kristian Evensen kristian.even...@gmail.com wrote: 2) When disconnecting any WIFI dongle, I always get a kernel oops. This happens irrespective of if the dongle is active (for example connected to network) or if I have just connected it to the router

ar71xx: Problems with USB WIFI dongles

Hello, I am currently working on a small project and I have come across a problem I have not been able to solve myself. My setup is as following, I have a TP-LINK WDR4300 (so ar71xx) router that will be used as an access point to share a WAN connection. The WAN connection is a different wifi. My

Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)

Hi all, After spending more time experimenting and trying to solve this problem, we have sort-of come to a conclusion. In case anyone else finds it interesting, I thought I should share it here. Our findings can be summarized as follows: - The problem is triggered by the switch from 3G to 2G. I

Strange behavior with ZTE MF821D (and possible other MDM9200 devices)

Hello, I am currently working on a project where we are building devices that will be placed on moving objects (buses, trains, etc.). The devices are routers (TP-Link WDR4300) based on the Atheros AR9344 SoC and running OpenWrt with kernel 3.10.18. The purpose of these devices is to measure the

Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)

Hei Bjørn, On Tue, Dec 3, 2013 at 3:37 PM, Bjørn Mork bj...@mork.no wrote: The most likely cause of this is a modem firmware crash. I don't think there is much you can do about that, except trying to avoid the situations which causes the crash or getting another modem. Ok, that is what I

Re: Strange behavior with ZTE MF821D (and possible other MDM9200 devices)

Hi Markus, On Tue, Dec 3, 2013 at 9:08 PM, Markus Gothe nietzs...@lysator.liu.se wrote: This is a know issue with some MF821D firmwares. I believe it is due to some sort of hibernation mode. Thank you very much for letting me know. Do you know of any strategies people have used to work around

Re: USB instabilities with Atheros AR9344

Thank you very much for another detailed reply. On Sat, Nov 30, 2013 at 4:55 PM, Alan Stern st...@rowland.harvard.edu wrote: By device, I mean the piece of hardware that is supposed to reply to the host. In your case that would be the modem (the hub does not make up replies to packets that

USB instabilities with Atheros AR9344

Hello, I am currently working on an embedded project based on the Atheros AR9344 SoC. As a prototype device, we are using the TP-Link TL-WDR4300 router (http://wiki.openwrt.org/toh/tp-link/tl-wdr4300) and latest OpenWRT trunk. The kernel is 3.10.18. We have over the last couple of weeks

Re: USB instabilities with Atheros AR9344

Hi, Thank you very much for the quick reply. On Fri, Nov 29, 2013 at 4:13 PM, Alan Stern st...@rowland.harvard.edu wrote: The most common reason for -71 errors is that the device failed to send a reply or handshake packet back to the host. Generally this is caused by a bug in the device's