from:"Kristian Evensen"

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

2018-02-01 Thread Kristian Evensen

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.

This patch should also be considered for -stable. The QMI-patch for this
modem is already in the -stable-queue.

v1->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/option.c
index b6320e3be429..2d53e14ff93b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struct urb *urb);
 #define QUECTEL_PRODUCT_EC21   0x0121
 #define QUECTEL_PRODUCT_EC25   0x0125
 #define QUECTEL_PRODUCT_BG96   0x0296
+#define QUECTEL_PRODUCT_EP06   0x0306
 
 #define CMOTECH_VENDOR_ID  0x16d8
 #define CMOTECH_PRODUCT_6001   0x6001
@@ -686,6 +687,10 @@ static const struct option_blacklist_info 
yuga_clm920_nc5_blacklist = {
.reserved = BIT(1) | BIT(4),
 };
 
+static const struct option_blacklist_info quectel_ep06_blacklist = {
+   .reserved = BIT(4) | BIT(5),
+};
+
 static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1200,6 +1205,8 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06),
+ .driver_info = (kernel_ulong_t)_ep06_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
-- 
2.14.1

--
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

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

2018-01-31 Thread Kristian Evensen

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
renaming/recycling and added a new blacklist entry. I can rename the
entry and update references as part of this commit. What would be an
appropriate name, something straight-forward like
"net_intf4_intf5_blacklist"?

BR,
Kristian
--
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

[PATCH] option: Add support for Quectel EP06

2018-01-30 Thread Kristian Evensen

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 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index b6320e3be429..2d53e14ff93b 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -241,6 +241,7 @@ static void option_instat_callback(struct urb *urb);
 #define QUECTEL_PRODUCT_EC21   0x0121
 #define QUECTEL_PRODUCT_EC25   0x0125
 #define QUECTEL_PRODUCT_BG96   0x0296
+#define QUECTEL_PRODUCT_EP06   0x0306
 
 #define CMOTECH_VENDOR_ID  0x16d8
 #define CMOTECH_PRODUCT_6001   0x6001
@@ -686,6 +687,10 @@ static const struct option_blacklist_info 
yuga_clm920_nc5_blacklist = {
.reserved = BIT(1) | BIT(4),
 };
 
+static const struct option_blacklist_info quectel_ep06_blacklist = {
+   .reserved = BIT(4) | BIT(5),
+};
+
 static const struct usb_device_id option_ids[] = {
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
{ USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
@@ -1200,6 +1205,8 @@ static const struct usb_device_id option_ids[] = {
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
{ USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96),
  .driver_info = (kernel_ulong_t)_intf4_blacklist },
+   { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06),
+ .driver_info = (kernel_ulong_t)_ep06_blacklist },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) },
{ USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003),
-- 
2.14.1

--
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

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

2017-11-07 Thread Kristian Evensen

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 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

[PATCH net] qmi_wwan: Add missing skb_reset_mac_header-call

2017-11-07 Thread Kristian Evensen

When we receive a packet on a QMI device in raw IP mode, we should call
skb_reset_mac_header() to ensure that skb->mac_header contains a valid
offset in the packet. While it shouldn't really matter, the packets have
no MAC header and the interface is configured as-such, it seems certain
parts of the network stack expects a "good" value in skb->mac_header.

Without the skb_reset_mac_header() call added in this patch, for example
shaping traffic (using tc) triggers the following oops on the first
received packet:

[  303.642957] skbuff: skb_under_panic: text:8f137918 len:177 put:67 
head:8e4b0f00 data:8e4b0eff tail:0x8e4b0fb0 end:0x8e4b1520 dev:wwan0
[  303.655045] Kernel bug detected[#1]:
[  303.658622] CPU: 1 PID: 1002 Comm: logd Not tainted 4.9.58 #0
[  303.664339] task: 8fdf05e0 task.stack: 8f15c000
[  303.668844] $ 0   :  0001 007a 
[  303.674062] $ 4   : 8149a2fc 8149a2fc 8149ce20 
[  303.679284] $ 8   : 0030 3878303a 31623465 20303235
[  303.684510] $12   : ded731e3 2626a277  03bd
[  303.689747] $16   : 8ef62b40 0043 8f137918 804db5fc
[  303.694978] $20   : 0001 0004 8fc13800 0003
[  303.700215] $24   : 0001 8024ab10
[  303.705442] $28   : 8f15c000 8fc19cf0 0043 802cc920
[  303.710664] Hi: 
[  303.713533] Lo: 74e58000
[  303.716436] epc   : 802cc920 skb_panic+0x58/0x5c
[  303.721046] ra: 802cc920 skb_panic+0x58/0x5c
[  303.725639] Status: 11007c03 KERNEL EXL IE
[  303.729823] Cause : 50800024 (ExcCode 09)
[  303.733817] PrId  : 0001992f (MIPS 1004Kc)
[  303.737892] Modules linked in: rt2800pci rt2800mmio rt2800lib qcserial 
ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib rndis_host qmi_wwan 
ppp_generic nf_nat_pptp nf_conntrack_pptp nf_conntrack_ipv6 mt76x2i
Process logd (pid: 1002, threadinfo=8f15c000, task=8fdf05e0, tls=77b3eee4)
[  303.962509] Stack :  80408990 8f137918 00b1 0043 8e4b0f00 
8e4b0eff 8e4b0fb0
[  303.970871] 8e4b1520 8fec1800 0043 802cd2a4 6e45 0043 
 8ef62000
[  303.979219] 8eef5d00 8ef62b40 8fea7300 8f137918   
0002bb01 793e5664
[  303.987568] 8ef08884 0001 8fea7300 0002 8fc19e80 8eef5d00 
0006 0003
[  303.995934]  8030ba90 0003 77ab3fd0 8149dc80 8004d1bc 
8f15c000 8f383700
[  304.004324] ...
[  304.006767] Call Trace:
[  304.009241] [<802cc920>] skb_panic+0x58/0x5c
[  304.013504] [<802cd2a4>] skb_push+0x78/0x90
[  304.017783] [<8f137918>] 0x8f137918
[  304.021269] Code: 00602825  0c02a3b4  24842888 <000c000d> 8c870060  8c8200a0 
 0007382b  00070336  8c88005c
[  304.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: Kristian Evensen <kristian.even...@gmail.com>
---
 drivers/net/usb/qmi_wwan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index db7279d5b250..5b22645c7c8c 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -499,6 +499,7 @@ static int qmi_wwan_rx_fixup(struct usbnet *dev, struct 
sk_buff *skb)
return 1;
}
if (rawip) {
+   skb_reset_mac_header(skb);
skb->dev = dev->net; /* normally set by eth_type_trans */
skb->protocol = proto;
return 1;
-- 
2.11.0

--
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

Re: Random xHCI HC died on device disconnect

2017-10-05 Thread Kristian Evensen

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 command
> ring
> and remove/move past the current command.
>
> Logs shows the command first timed out, and xhci then failing to stop the
> command ring.
> when trying to abort the command.
>
> To me it looks like xHC ends up in a state that we can't recover from
> without resetting xHC.
> xhci Module reload or rebinding device and driver is needed

I thought I had scared the error away, but it just happened. I figured
out how to build xhci as a module for my board and reloading
(rmmod/modprobe) the module recovers the host controller. So while not
very elegant, a script which checks dmesg for this error message and
reloads xhci in case error happens is good enough in my case.

Thanks for all the help!
Kristian
--
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

Re: Random xHCI HC died on device disconnect

2017-10-03 Thread Kristian Evensen

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_wwan 4-1:1.4: Tx URB error: -19

I was not thinking clearly when I wrote the email. The reason this
message kept looping over and over was that I kept trying to
communicate with the modem. When I stopped my tool, the message
stopped. However, the host controller is still dead, so even if I try
to disconnect the device using GPIO, nothing happens. I thought the
log of when the error occurred was lost due to limited buffers, but I
was wrong and I have the following in dmesg when the error strikes:

[15986.400431] usb 4-1: USB disconnect, device number 13
[15986.400454] qmi_wwan 4-1:1.4: nonzero urb status received: -71
[15986.411366] qmi_wwan 4-1:1.4: wdm_int_callback - 0 bytes
[15986.416692] qmi_wwan 4-1:1.4: wdm_int_callback - usb_submit_urb
failed with result -19
[15986.424816] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[15986.432886] option 4-1:1.0: device disconnected
[15986.437647] option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
[15986.445765] option 4-1:1.1: device disconnected
[16001.110698] xhci-hcd f10f8000.usb3: Stopped the command ring
failed, maybe the host is dead
[16001.119077] xhci-hcd f10f8000.usb3: Abort command ring failed
[16001.124949] xhci-hcd f10f8000.usb3: HC died; cleaning up
[16100.854819] qmi_wwan 4-1:1.4: Tx URB error: -19
[16105.854944] qmi_wwan 4-1:1.4: Tx URB error: -19
[16110.855052] qmi_wwan 4-1:1.4: Tx URB error: -19
[16115.855159] qmi_wwan 4-1:1.4: Tx URB error: -19
[16120.855285] qmi_wwan 4-1:1.4: Tx URB error: -19
[16125.855396] qmi_wwan 4-1:1.4: Tx URB error: -19

I am bit surprised to see the HC-related messages. Maybe I missed a
place where the timer is stopped or something, time to investigate!

-Kristian
--
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

Re: Random xHCI HC died on device disconnect

2017-10-03 Thread Kristian Evensen

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 be triggered. Instead
of "HC died...", I now get the following message looping over and
over:

[16870.871935] qmi_wwan 4-1:1.4: Tx URB error: -19

Another difference from before is that the modem does not get
disconnected from host, i.e., it is still visible in lsusb. Trying to
for example deauthorize the device just hangs, which I guess is as
expected. Is there any way to clear the TX queue, but not halt the hc?
I am not familiar with the xhci-code, but it seems that
xhci_kill_endpoint_urbs does something similar to what I want. Perhaps
it is possible to change the watchdog to flush queue, but not kill
controller.

A soft reboot, as expected, solved the issue. I guess the soft reboot
indicates that this problem should be solvable without a reboot. I
found open Marvell's 4.4 kernel during the afternoon and see that they
power down/up phy during suspend/resumse. I will try to use that for
inspiration and see what happens.

-Kristian
--
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

Re: Random xHCI HC died on device disconnect

2017-10-03 Thread Kristian Evensen

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 based xhci it would be something like:
> echo :00:14.0 > /sys/bus/pci/drivers/xhci_hcd/unbind
> echo :00:14.0 > /sys/bus/pci/drivers/xhci_hcd/bind

xhci is unfortunately not a module on my system, but I will try to
build it is a module today. I did try bind/unbind yesterday, but
unfortunately without any success. unbind worked fine, but bind only
caused an error message. I can't remember the exact error message (I
unfortunately forgot to write it down), but the code was -22 and I
think the message was something that communication with hub failed.

> If you want to try messing around with the driver itself you could try to
> just disable the xhci stop command timer.
> The timer is there for a reason, but it's also possible that your command
> queue is
> just clogged because its trying to address the faulty device.
> You could play around and remove the timer and see what happens:

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.

I performed some additional tests yesterday and this morning, and it
seems you are right in that the error is triggered by messages being
stuck in the queue when the device is disconnected. For my new set of
tests, I made a small script which only restarts the modem using GPIO
at some interval. I.e., there is no data sent to the modem. I left the
script running over night, and saw no errors. I then started my
default tool, which configures the modem and performs the restart, and
the error appeared within a couple of hours.

Thanks for all the help,
Kristian
--
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

Random xHCI HC died on device disconnect

2017-10-02 Thread Kristian Evensen

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 when I restart the USB-port I get the following error
in dmesg:

[12446.639458] qmi_wwan 4-1:1.4: nonzero urb status received: -71
[12446.639462] qmi_wwan 4-1:1.4: wdm_int_callback - 0 bytes
[12446.639466] qmi_wwan 4-1:1.4: wdm_int_callback - usb_submit_urb
failed with result -19
[12446.658760] option1 ttyUSB0: GSM modem (1-port) converter now
disconnected from ttyUSB0
[12446.666837] option 4-1:1.0: device disconnected
[12446.671576] option1 ttyUSB1: GSM modem (1-port) converter now
disconnected from ttyUSB1
[12446.679686] option 4-1:1.1: device disconnected
[12451.763245] xhci-hcd f10f8000.usb3: xHCI host not responding to
stop endpoint command.
[12451.771187] xhci-hcd f10f8000.usb3: Assuming host is dying, halting host.
[12451.778027] xhci-hcd f10f8000.usb3: HC died; cleaning up
[12451.783589] option1 ttyUSB2: GSM modem (1-port) converter now
disconnected from ttyUSB2
[12451.791654] option 4-1:1.2: device disconnected
[12451.796416] option1 ttyUSB3: GSM modem (1-port) converter now
disconnected from ttyUSB3
[12451.804530] option 4-1:1.3: device disconnected
[12451.809206] qmi_wwan 4-1:1.4 wwan0: unregister 'qmi_wwan'
usb-f10f8000.usb3-1, WWAN/QMI device

After this, the port is dead until I reboot the device and it is
sufficient to do a soft reboot in order to bring the port back. Most
of the time, restarting the port works fine and the time it takes for
the error to occur seems random.

In order to rule out (or at least reduce the probability of) that
there is something wrong with the board I am testing, I found two
other Armada-boards with upstream-support and compiled kernel 4.14-rc3
for them. The modem can be rebooted using AT-commands, so I created a
small script which contained a loop where I rebooted the modem as soon
as possible. Doing this, I was able to replicate the error I saw on my
custom board-

Does anyone have any tips on where to start looking, how to solve this
issue or how to work around it? For me, if there is a way to restart
the host controller, then that would be sufficient as I only have one
USB device connected. When searching online, I find lots of references
to similar issues, but they all (or at least the ones where a solution
has been found) seem to related to suspend/resume.

Thanks in advance for any help,
Kristian
--
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

[PATH net v2] cdc_ether: Fix handling connection notification

2016-12-01 Thread Kristian Evensen

Commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
introduced a work-around in usbnet_cdc_status() for devices that exported
cdc carrier on twice on connect. Before the commit, this behavior caused
the link state to be incorrect. It was assumed that all CDC Ethernet
devices would either export this behavior, or send one off and then one on
notification (which seems to be the default behavior).

Unfortunately, it turns out multiple devices sends a connection
notification multiple times per second (via an interrupt), even when
connection state does not change. This has been observed with several
different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
After bfe9b9d2df66, the link state has been set as down and then up for
each notification. This has caused a flood of Netlink NEWLINK messages and
syslog to be flooded with messages similar to:

cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped

This commit fixes the behavior by reverting usbnet_cdc_status() to how it
was before bfe9b9d2df66. The work-around has been moved to a separate
status-function which is only called when a known, affect device is
detected.

v1->v2:

* Do not open-code netif_carrier_ok() (thanks Henning Schild).
* Call netif_carrier_off() instead of usb_link_change(). This prevents
calling schedule_work() twice without giving the work queue a chance to be
processed (thanks Bjørn Mork).

Fixes: bfe9b9d2df66 ("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 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 45e5e43..fe7b288 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,12 +388,6 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
-
-   /* Work-around for devices with broken off-notifications */
-   if (event->wValue &&
-   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
-   usbnet_link_change(dev, 0, 0);
-
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -466,6 +460,36 @@ static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, 
struct sk_buff *skb)
return 1;
 }
 
+/* Ensure correct link state
+ *
+ * Some devices (ZTE MF823/831/910) export two carrier on notifications when
+ * connected. This causes the link state to be incorrect. Work around this by
+ * always setting the state to off, then on.
+ */
+void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
+{
+   struct usb_cdc_notification *event;
+
+   if (urb->actual_length < sizeof(*event))
+   return;
+
+   event = urb->transfer_buffer;
+
+   if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
+   usbnet_cdc_status(dev, urb);
+   return;
+   }
+
+   netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
+ event->wValue ? "on" : "off");
+
+   if (event->wValue &&
+   netif_carrier_ok(dev->net))
+   netif_carrier_off(dev->net);
+
+   usbnet_link_change(dev, !!event->wValue, 0);
+}
+
 static const struct driver_infocdc_info = {
.description =  "CDC Ethernet Device",
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
@@ -481,7 +505,7 @@ static const struct driver_info zte_cdc_info = {
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
.bind = usbnet_cdc_zte_bind,
.unbind =   usbnet_cdc_unbind,
-   .status =   usbnet_cdc_status,
+   .status =   usbnet_cdc_zte_status,
.set_rx_mode =  usbnet_cdc_update_filter,
.manage_power = usbnet_manage_power,
.rx_fixup = usbnet_cdc_zte_rx_fixup,
-- 
2.9.3

--
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

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

2016-11-30 Thread Kristian Evensen

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;
>> +
>> + if (urb->actual_length < sizeof(*event))
>> + return;
>> +
>> + event = urb->transfer_buffer;
>> +
>> + if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
>> + usbnet_cdc_status(dev, urb);
>> + return;
>> + }
>> +
>> + netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
>> +   event->wValue ? "on" : "off");
>> +
>> + if (event->wValue &&
>> + !test_bit(__LINK_STATE_NOCARRIER, >net->state))
>> + usbnet_link_change(dev, 0, 0);
>> +
>> + usbnet_link_change(dev, !!event->wValue, 0);
>> +}
>
> As Henning said: Use netif_carrier_ok instead of open coding it.
>
> But I also think you need to replace the first usbnet_link_change() with
> a plain netif_carrier_off(dev->net).  Calling usbnet_link_change() twice
> here is only going to set off the "kevent XX may have been dropped"
> message since you call schedule_work() twice without giving the work
> queue a chance to be processed.  No need to do that.

Thanks for the feedback and agree. Will submit a v2 tomorrow.

-Kristian
--
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

[PATCH net] cdc_ether: Fix handling connection notification

2016-11-30 Thread Kristian Evensen

Commit bfe9b9d2df66 ("cdc_ether: Improve ZTE MF823/831/910 handling")
introduced a work-around in usbnet_cdc_status() for devices that exported
cdc carrier on twice on connect. Before the commit, this behavior caused
the link state to be incorrect. It was assumed that all CDC Ethernet
devices would either export this behavior, or send one off and then one on
notification (which seems to be the default behavior).

Unfortunately, it turns out multiple devices sends a connection
notification multiple times per second (via an interrupt), even when
connection state does not change. This has been observed with several
different USB LAN dongles (at least), for example 13b1:0041 (Linksys).
After bfe9b9d2df66, the link state has been set as down and then up for
each notification. This has caused a flood of Netlink NEWLINK messages and
syslog to be flooded with messages similar to:

cdc_ether 2-1:2.0 eth1: kevent 12 may have been dropped

This commit fixes the behavior by reverting usbnet_cdc_status() to how it
was before bfe9b9d2df66. The work-around has been moved to a separate
status-function which is only called when a known, affect device is
detected.

Fixes: bfe9b9d2df66 ("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 insertions(+), 7 deletions(-)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 45e5e43..8c628ea 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,12 +388,6 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
-
-   /* Work-around for devices with broken off-notifications */
-   if (event->wValue &&
-   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
-   usbnet_link_change(dev, 0, 0);
-
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -466,6 +460,36 @@ static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, 
struct sk_buff *skb)
return 1;
 }
 
+/* Ensure correct link state
+ *
+ * Some devices (ZTE MF823/831/910) export two carrier on notifications when
+ * connected. This causes the link state to be incorrect. Work around this by
+ * always setting the state to off, then on.
+ */
+void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
+{
+   struct usb_cdc_notification *event;
+
+   if (urb->actual_length < sizeof(*event))
+   return;
+
+   event = urb->transfer_buffer;
+
+   if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
+   usbnet_cdc_status(dev, urb);
+   return;
+   }
+
+   netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
+ event->wValue ? "on" : "off");
+
+   if (event->wValue &&
+   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
+   usbnet_link_change(dev, 0, 0);
+
+   usbnet_link_change(dev, !!event->wValue, 0);
+}
+
 static const struct driver_infocdc_info = {
.description =  "CDC Ethernet Device",
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
@@ -481,7 +505,7 @@ static const struct driver_info zte_cdc_info = {
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
.bind = usbnet_cdc_zte_bind,
.unbind =   usbnet_cdc_unbind,
-   .status =   usbnet_cdc_status,
+   .status =   usbnet_cdc_zte_status,
.set_rx_mode =  usbnet_cdc_update_filter,
.manage_power = usbnet_manage_power,
.rx_fixup = usbnet_cdc_zte_rx_fixup,
-- 
2.9.3

--
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

Re: cdc_ether flooding kernel logs since bfe9b9d2d

2016-11-30 Thread Kristian Evensen

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 options is to remove the
>> code from the generic usbnet_cdc_status() function and move it to a
>> ZTE-specific status function inside cdc_ether.
>
> Hi,
>
> please do so. This looks like the cleanest approach.

Ok, great. I will do this right away and submit a patch tonight.

Again, sorry for this.

-Kristian
--
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

Re: cdc_ether flooding kernel logs since bfe9b9d2d

2016-11-29 Thread Kristian Evensen

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 been dropped" in the kernel log all the time.

Thanks for letting me/us know. I spent some time looking into the
problem now and can reproduce it with a fairly recent cdc_ether dongle
that I just got (also Linksys). The cause is that after every
(incoming?) interrupt, usbnet_cdc_status() is called. Each interrupt
contains a USB_CDC_NOTIFY_NETWORK_CONNECTION notification, reporting
that the carrier is on. After my change, this will cause the interface
to be set as down and then up for each interrupt, since the carrier is
already is already available (__LINK_STATE_NOCARRIER is not set). I
also captured the traffic on the correct USB bus and see these
interrupts happening multiple times per second.

When re-testing with the devices I used when developing the patch, I
do not see this behavior. I only see one (with devices I assumed to be
working fine) or two (MF823/910) interrupts. Other than that, it is
mostly bulk transfers.

I don't know which of the two behaviors (if any) are "correct" or what
the best way to solve this problem is. One options is to remove the
code from the generic usbnet_cdc_status() function and move it to a
ZTE-specific status function inside cdc_ether.

-Kristian
--
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

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

2016-07-21 Thread Kristian Evensen

The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct 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.

v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).

v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, 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>
Acked-by: Oliver Neukum <oneu...@suse.com>
---
 drivers/net/usb/cdc_ether.c | 51 +
 1 file changed, 51 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..c47ec0a 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,6 +388,12 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
+
+   /* Work-around for devices with broken off-notifications */
+   if (event->wValue &&
+   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
+   usbnet_link_change(dev, 0, 0);
+
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -432,6 +438,34 @@ int usbnet_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
 }
 EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
 
+static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+   int status = usbnet_cdc_bind(dev, intf);
+
+   if (!status && (dev->net->dev_addr[0] & 0x02))
+   eth_hw_addr_random(dev->net);
+
+   return status;
+}
+
+/* Make sure packets have correct destination MAC address
+ *
+ * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
+ * device sends packets with a static, bogus, random MAC address (event if
+ * device MAC address has been updated). Always set MAC address to that of the
+ * device.
+ */
+static int usbnet_cdc_zte_rx_fixup(st

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

2016-07-19 Thread Kristian Evensen

The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct 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.

v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Olive).
* Rework logic in the ZTE bind-function a bit.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, 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_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..874caad 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,6 +388,12 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
+
+   /* Work-around for devices with broken off-notifications */
+   if (event->wValue &&
+   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
+   usbnet_link_change(dev, 0, 0);
+
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -432,6 +438,37 @@ int usbnet_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
 }
 EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
 
+static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+   int status = usbnet_cdc_bind(dev, intf);
+
+   if (!status && (dev->net->dev_addr[0] & 0x02))
+   eth_hw_addr_random(dev->net);
+
+   return status;
+}
+
+/* Make sure packets have correct destination MAC address
+ *
+ * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
+ * device sends packets with a static, bogus, random MAC address (event if
+ * device MAC address has been updated). Always set MAC address to that of the
+ * device.
+ */
+static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+   u8 num_buggy_hwaddrs;
+   u8 buggy_hwaddrs_idx = 0;
+
+   if (skb->len < E

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

2016-07-19 Thread Kristian Evensen

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)
>> return status;
>> }
>>
>> +   if (dev->net->dev_addr[0] & 0x02)
>> +   eth_hw_addr_random(dev->net);
>> +
>> return 0;
>>  }
>>  EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
>>
>> +static int usbnet_cdc_zte_bind(struct usbnet *dev, struct
>> usb_interface *intf)
>> +{
>> +   int status = usbnet_cdc_bind(dev, intf);
>> +
>> +   if (status)
>> +   return status;
>> +
>> +   if (dev->net->dev_addr[0] & 0x02)
>> +   eth_hw_addr_random(dev->net);
>> +
>> +   return 0;
>> +}
>
> That really makes no sense.

Ops, my bad. Thanks for catching it. The check for random hw_addr
should only be in the zte_bind() function.

-Kristian
--
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

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

2016-07-19 Thread Kristian Evensen

The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.

This patch tries to improve the handling of ZTE devices by doing the
following:

* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.

* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.

* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct 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.

v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, 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_ether.c | 60 +
 1 file changed, 60 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..49c2a4c 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,6 +388,12 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
+
+   /* Work-around for devices with broken off-notifications */
+   if (event->wValue &&
+   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
+   usbnet_link_change(dev, 0, 0);
+
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -428,10 +434,47 @@ int usbnet_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
return status;
}
 
+   if (dev->net->dev_addr[0] & 0x02)
+   eth_hw_addr_random(dev->net);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
 
+static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface *intf)
+{
+   int status = usbnet_cdc_bind(dev, intf);
+
+   if (status)
+   return status;
+
+   if (dev->net->dev_addr[0] & 0x02)
+   eth_hw_addr_random(dev->net);
+
+   return 0;
+}
+
+/* Make sure packets have correct destination MAC address
+ *
+ * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
+ * device sends packets with a static, bogus, random MAC address (event if
+ * device MAC address has been updated). Always set MAC address to that of the
+ * device.
+ */
+static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+   u8 num_buggy_hwaddrs;
+   u8 buggy_hwaddrs_idx

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

2016-07-19 Thread Kristian Evensen

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 PIDs
>> and leave usbnet as is? Or am I misunderstanding how to add this
>> functionality to usbnet?
>>
>
> Matching on the usb id is probably not a great idea, there is more id's
> than the two you have found and there is also more than two non-unique mac
> addresses.
>
> Example:
>
> 0200FFAA  19d2:1589/1592/1595
> 020CE70B0102  19d2:1040/1048/1405
>
> You can easily find them by googling them, without colon separators you
> will find them in verbose lsusb listings, with colons you will find them in
> dmesg pastings.
>
> I would probably have found more dupes if users had refrained from using the
> stupid usbdevices cmd which removes almost all interesting info from device
> listings in internet foras.

Thanks for letting me know. It seems that the static MAC behaviour is
the default behaviour of ZTE-devices that use cdc_ether. Unless anyone
objects, I will make the following changes for v2:

* Create a ZTE-specific bind method in cdc_ether that checks for a
random MAC and generates a new MAC if found.
* Use the ZTE-specific bind + rx fixup for all ZTE cdc_ether devices
by default, and add exceptions if we find any devices not displaying
this behaviour. I see there are already five ZTE devices with separate
entries in the products-array in cdc_ether.

-Kristian
--
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

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

2016-07-19 Thread Kristian Evensen

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
>> qmi_wwan.c. And there is probably more code/assumptions like that in
>> the network stack.
>
> In this case please use special cases for usbnet, too.
> We need a quirk.

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 PIDs
and leave usbnet as is? Or am I misunderstanding how to add this
functionality to usbnet?

-Kristian
--
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

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

2016-07-18 Thread Kristian Evensen

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 ethernet code, at least not yet, but I agree it would make sense
>> to move it to for example usbnet_core(). If you agree, I can prepare a
>> patch for it.
>
> I don't see how it would be specific for a subsystem. If the patch
> is correct, it belongs into the networking core.

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
qmi_wwan.c. And there is probably more code/assumptions like that in
the network stack.

-Kristian
--
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

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

2016-07-18 Thread Kristian Evensen

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 ethernet code, at least not yet, but I agree it would make sense
>> to move it to for example usbnet_core(). If you agree, I can prepare a
>> patch for it.
>
> I don't see how it would be specific for a subsystem. If the patch
> is correct, it belongs into the networking core.

To me it sounds a bit intrusive to change the networking core for
something that has so far only been seen with devices belonging to one
subsystem, but I will do it if required. I guess David M. will have an
opinion on if we should add this fix on a per-driver basis, in usbnet
or in the networking core? If we go for the latter, what would be
correct place for this piece of code, register_netdevice()?

-Kristian
--
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

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

2016-07-18 Thread Kristian Evensen

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 code. Your code is good, but you are putting it in the wrong
> places.

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 ethernet code, at least not yet, but I agree it would make sense
to move it to for example usbnet_core(). If you agree, I can prepare a
patch for it.
--
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

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

2016-07-18 Thread Kristian Evensen

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, these devices export
>> a REST API which can also be used to control the type of device. So far, on
>> Linux, the devices have been seen as RNDIS or CDC Ether.
>>
>> When CDC Ether is used, devices of the same type are, as with RNDIS,
>> exported with the same, bogus random MAC address. In addition, the devices
>
> Please explain. If the MAC is random, I fail to see why the host would
> be any better at making up a MAC.

Sorry for not explaining this properly. The problem is that all
devices of the same type store the same value in iMACAddress. On all
MF831/MF910s (that I have seen) 36:4b:50:b7:ef:da is stored in this
value, while 36:4b:50:b7:ef:38 is stored on MF823. In order to ensure
that all devices on a host has a unique MAC-address, I think it is
better to generate a new random MAC on the host than to trust the
value returned from the device.

>> * If a random MAC is read from device, then generate a new random MAC
>> address. This fix will apply to all devices using cdc_ether, but that
>> should be ok as we will also fix similar mistakes from other
>> manufacturers.
>
> I am not really happy with this.
>
> If this is specific to the device a quirk should be used. If it is a
> truly generic misdesign, it does not belong into cdc-ether. It should go
> into the generic layer.

We saw the same behaviour when these devices are exposed as RNDIS and
decided to apply a generic fix instead of limiting ourself to for
example the two, known bogus MAC address. See commit
a5a18bdf7453d505783e40e47ebb84bfdd35f93b and the thread "[PATCH]
rndis_host: Set random MAC for ZTE MF910"
(http://www.spinics.net/lists/linux-usb/msg143727.html) for the
discussion.

However, I have no strong objections towards for example checking
against the two bad MAC addresses before generating a random MAC.

-Kristian
--
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

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

2016-07-18 Thread Kristian Evensen

The firmware in the ZTE MF823/831/910 modems/mifis use OS fingerprinting to
determine which type of device to export. In addition, these devices export
a REST API which can also be used to control the type of device. So far, on
Linux, the devices have been seen as RNDIS or CDC Ether.

When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use this MAC when sending
traffic routed from external networks. And as a final feature, the devices
sometimes export the link state incorrectly.

This patch tries to improve the handling of these devices by doing the
following:

* If a random MAC is read from device, then generate a new random MAC
address. This fix will apply to all devices using cdc_ether, but that
should be ok as we will also fix similar mistakes from other
manufacturers.

* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.

This change will also affect all devices, but as with the MAC-fix it should
take care of similar mistakes. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.

* Add an rx_fixup-function (and a new driver info-struct) which is used by
these three devices (identified either as PID 0x1405 or 0x1408). The
rx_fixup-function replaces the destination MAC address in the skb with that
of the device. I have not seen a revision of these three device that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.

I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct 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.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 7cba2c3..2325097 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -388,6 +388,12 @@ void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
  event->wValue ? "on" : "off");
+
+   /* Work-around for devices with broken off-notifications */
+   if (event->wValue &&
+   !test_bit(__LINK_STATE_NOCARRIER, >net->state))
+   usbnet_link_change(dev, 0, 0);
+
usbnet_link_change(dev, !!event->wValue, 0);
break;
case USB_CDC_NOTIFY_SPEED_CHANGE:   /* tx/rx rates */
@@ -428,10 +434,34 @@ int usbnet_cdc_bind(struct usbnet *dev, struct 
usb_interface *intf)
return status;
}
 
+   if (dev->net->dev_addr[0] & 0x02)
+   eth_hw_addr_random(dev->net);
+
return 0;
 }
 EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
 
+/* Make sure packets have correct destination MAC address
+ *
+ * A firmware bug observed on some devices (ZTE MF823/831/910) is that the
+ * device sends packets with a static, bogus, random MAC address (event if
+ * device MAC address has been updated). Always set MAC address to that of the
+ * device.
+ */
+static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+{
+   u8 num_buggy_hwaddrs;
+   u8 buggy_hwaddrs_idx = 0;
+
+   if (skb->len < ETH_HLEN || !(skb->data[0] & 0x02))
+   return 1;
+
+   skb_reset_mac_header(skb);
+   ether_addr_copy(eth_hdr(skb)->h_dest, dev->net->dev_addr);
+
+   return 1;
+}
+
 static const struct driver_infocdc_info = {
.description =  "CDC Ethernet Device",
.flags =FLAG_ETHER | FLAG_POINTTOPOINT,
@@ -442,6 +472,17 @@ static const struct driver_infocdc_info = {
.manage_power = usbnet_manage_power,
 };
 
+static const struct driver_infozte_cdc_info = {
+   .description =  "ZTE MF823/831/910 CDC Ethernet Device",
+   .flags =FLAG_ETHER | FLAG_POINTTOPOINT,
+   .bind = usbnet_cdc_bind,
+   .unbind =   usbnet_cdc_unbind,
+   .status =   usbnet_cdc_status,
+   .set_rx_mode =  usbnet_cdc_update_filter,

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

2016-07-14 Thread Kristian Evensen

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 we read a random MAC from device.

Also, changed the memcpy() to ether_addr_copy(), as pointed out by
checkpatch.

Suggested-by: Bjørn Mork <bj...@mork.no>
Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 drivers/net/usb/rndis_host.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index 524a47a281..4f4f71b 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -428,7 +428,11 @@ generic_rndis_bind(struct usbnet *dev, struct 
usb_interface *intf, int flags)
dev_err(>dev, "rndis get ethaddr, %d\n", retval);
goto halt_fail_and_release;
}
-   memcpy(net->dev_addr, bp, ETH_ALEN);
+
+   if (bp[0] & 0x02)
+   eth_hw_addr_random(net);
+   else
+   ether_addr_copy(net->dev_addr, bp);
 
/* set a nonzero filter to enable data transfers */
memset(u.set, 0, sizeof *u.set);
-- 
2.5.0

--
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

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

2016-07-14 Thread Kristian Evensen

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] & 0x02)
>> eth_hw_addr_random(net);
>> else
>> ether_addr_copy(net->dev_addr, bp);
>>
>> That would catch similar screwups from other vendors too.
>
> Great idea, thanks. After submitting the patch I found some other
> devices with a similar bug, and there are probably even more out
> there. I will update patch and resubmit.

Oh, and I forgot to say, please ignore this patch. I will change the
title and description to better describe the functionality.

-Kristian
--
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

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

2016-07-14 Thread Kristian Evensen

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 from other vendors too.

Great idea, thanks. After submitting the patch I found some other
devices with a similar bug, and there are probably even more out
there. I will update patch and resubmit.

-Kristian
--
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

[PATCH] rndis_host: Set random MAC for ZTE MF910

2016-07-13 Thread Kristian Evensen

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
checkpatch.

Signed-off-by: Kristian Evensen <kristian.even...@gmail.com>
---
 drivers/net/usb/rndis_host.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/usb/rndis_host.c b/drivers/net/usb/rndis_host.c
index 524a47a281..85bdbdf 100644
--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -295,6 +295,9 @@ static const struct net_device_ops rndis_netdev_ops = {
.ndo_validate_addr  = eth_validate_addr,
 };
 
+/* well-known buggy ZTE MF910 MAC address */
+static const u8 buggy_zte_addr[ETH_ALEN] = {0x36, 0x4b, 0x50, 0xb7, 0xef, 
0xda};
+
 int
 generic_rndis_bind(struct usbnet *dev, struct usb_interface *intf, int flags)
 {
@@ -428,7 +431,11 @@ generic_rndis_bind(struct usbnet *dev, struct 
usb_interface *intf, int flags)
dev_err(>dev, "rndis get ethaddr, %d\n", retval);
goto halt_fail_and_release;
}
-   memcpy(net->dev_addr, bp, ETH_ALEN);
+
+   if (ether_addr_equal(bp, buggy_zte_addr))
+   eth_hw_addr_random(net);
+   else
+   ether_addr_copy(net->dev_addr, bp);
 
/* set a nonzero filter to enable data transfers */
memset(u.set, 0, sizeof *u.set);
-- 
2.5.0

--
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

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

2016-01-06 Thread Kristian Evensen

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: 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 c6f7a69..ab3b86c 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -2408,6 +2408,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICK16F1454) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICK16F1454_V2) 
},
{ HID_USB_DEVICE(USB_VENDOR_ID_NATIONAL_SEMICONDUCTOR, 
USB_DEVICE_ID_N_S_HARMONY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100 + 
20) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 8b78a7f..16d3077 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -664,6 +664,7 @@
 #define USB_DEVICE_ID_PICOLCD  0xc002
 #define USB_DEVICE_ID_PICOLCD_BOOTLOADER   0xf002
 #define USB_DEVICE_ID_PICK16F1454  0x0042
+#define USB_DEVICE_ID_PICK16F1454_V2   0xf2f7
 
 #define USB_VENDOR_ID_MICROSOFT0x045e
 #define USB_DEVICE_ID_SIDEWINDER_GV0x003b
-- 
2.5.0

--
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

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

2015-01-20 Thread Kristian Evensen

The Microchip Pick16F1454 is exported as a HID device and is used by for example
the Yepkit YKUSH three-port switchable USB hub. However, it is not an actual
HID-device. On the Yepkit, it is used to power up/down the ports on the hub. The
HID driver should ignore this device.

Signed-off-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 +2328,7 @@ static const struct hid_device_id hid_ignore_list[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MCC, USB_DEVICE_ID_MCC_PMD1208LS) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT1) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICKIT2) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_MICROCHIP, USB_DEVICE_ID_PICK16F1454) },
{ HID_USB_DEVICE(USB_VENDOR_ID_NATIONAL_SEMICONDUCTOR, 
USB_DEVICE_ID_N_S_HARMONY) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ONTRAK, USB_DEVICE_ID_ONTRAK_ADU100 + 
20) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 9243359..8df4744 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -638,6 +638,7 @@
 #define USB_DEVICE_ID_PICKIT2  0x0033
 #define USB_DEVICE_ID_PICOLCD  0xc002
 #define USB_DEVICE_ID_PICOLCD_BOOTLOADER   0xf002
+#define USB_DEVICE_ID_PICK16F1454  0x0042
 
 #define USB_VENDOR_ID_MICROSOFT0x045e
 #define USB_DEVICE_ID_SIDEWINDER_GV0x003b
-- 
2.1.0

--
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

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

2015-01-19 Thread Kristian Evensen

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 be done in userspace, and using usbfs/libusb should be really
 simple for this device from what the driver looks like.

 So, care to slim down the patch a bunch and resend?

Sure, no problem. You want a patch containing only the HID-parts?

My reason for adding this as a kernel driver was to ease usage of the
device in scenarios where using libusb is not possible or desirable.
For example embedded devices with space constraints or being able to
restart USB ports from Bash-scripts. One use-case I have had for the
driver is a script which monitors AT-modems by sending AT to the
serial device, and restart the port by pipeing a value into portX if
no reply has been received for a certain amount of time.

-Kristian
--
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

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

2015-01-02 Thread Kristian Evensen

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 to fix, or at least improve, the situation by setting the MAC
address of devices with this firmware bug to a random address. I tested the
patch with two devices that has this firmware bug (Huawei E398 and E392), and
network traffic worked fine after changing the address.

Signed-off-by: Kristian Evensen kristian.even...@gmail.com
---
 drivers/net/usb/qmi_wwan.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index db21af8..30a716f 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -56,6 +56,8 @@ struct qmi_wwan_state {
 /* default ethernet address used by the modem */
 static const u8 default_modem_addr[ETH_ALEN] = {0x02, 0x50, 0xf3};
 
+static const u8 buggy_fw_addr[ETH_ALEN] = {0x00, 0xa0, 0xc6, 0x00, 0x00, 0x00};
+
 /* Make up an ethernet header if the packet doesn't have one.
  *
  * A firmware bug common among several devices cause them to send raw
@@ -332,10 +334,12 @@ next_desc:
usb_driver_release_interface(driver, info-data);
}
 
-   /* Never use the same address on both ends of the link, even
-* if the buggy firmware told us to.
+   /* Never use the same address on both ends of the link, even if the
+* buggy firmware told us to. Or, if device is assigned the well-known
+* buggy firmware MAC address, replace it with a random address,
 */
-   if (ether_addr_equal(dev-net-dev_addr, default_modem_addr))
+   if (ether_addr_equal(dev-net-dev_addr, default_modem_addr) ||
+   ether_addr_equal(dev-net-dev_addr, buggy_fw_addr))
eth_hw_addr_random(dev-net);
 
/* make MAC addr easily distinguishable from an IP header */
-- 
1.9.1

--
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

Re: ar71xx: Problems with USB WIFI dongles

2014-08-11 Thread Kristian Evensen

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.
 The kernel oops looks like the following (the crash happens at the
 same place independent of device):

 [  429.73] usb 1-1.1.5.4: USB disconnect, device number 10
 [  429.76] CPU 0 Unable to handle kernel paging request at virtual
 address 00100104, epc == 86e93018, ra == 86e93010
 [  429.77] Oops[#1]:
 [  429.77] CPU: 0 PID: 292 Comm: khubd Not tainted 3.14.12 #4
 [  429.77] task: 878ad770 ti: 87b0c000 task.ti: 87b0c000
 [  429.77] $ 0   :   00200200 00100100
 [  429.77] $ 4   : 87b0dce0 87b0dee0 8035 0008
 [  429.77] $ 8   : 00090040 86a6a080 0020 00090040
 [  429.77] $12   : 0013 000e 0007 0001
 [  429.77] $16   : 85cc91a0 87b0dcd8 00100100 85cc91a8
 [  429.77] $20   : 85cc91a0 00200200 86948000 87b41838
 [  429.77] $24   : 80327df0 8010fe04
 [  429.77] $28   : 87b0c000 87b0dcc8  86e93010
 [  429.77] Hi: 0350
 [  429.77] Lo: 0006
 [  429.77] epc   : 86e93018
 ieee80211_remove_interfaces+0x128/0x1b4 [mac80211]
 [  429.77] Not tainted
 [  429.77] ra: 86e93010
 ieee80211_remove_interfaces+0x120/0x1b4 [mac80211]
 [  429.77] Status: 1100dc03 KERNEL EXL IE
 [  429.77] Cause : 008c
 [  429.77] BadVA : 00100104
 [  429.77] PrId  : 0001974c (MIPS 74Kc)
 [  429.77] Modules linked in: ath9k rtl8192se rtl8192de rtl8192cu
 rtl8192ce ath9k_htc ath9k_common rtl_usb rtl_pci pppoe ppp_async
 option iptable_nat ath9k_hw ath usb_wwan smsc95xx rtlwifi rtl8187
 rt73usb rt2x00usb rt2x00lib rndis_host qmi_wwan pppox ppp_generic
 nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE huawei_cdc_ncm
 cfg80211 cdc_ncm cdc_ether ax88179_178a asix xt_time xt_tcpudp
 xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota
 xt_pkttype xt_owner xt_nfacct xt_nat xt_multiport xt_mark xt_mac
 xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack
 xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS
 xt_REDIRECT xt_NFQUEUE xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY
 usbserial usbnet ts_kmp ts_fsm ts_bm slhc rtl8192c_common
 nfnetlink_queue nfnetlink_acct nf_nat_irc nf_nat_ftp nf_nat
 nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw
 iptable_mangle iptable_filter ipt_REJECT ipt_ECN ipheth ip_tables
 crc16 crc_itu_t crc_ccitt compat cdc_wdm cdc_acm act_connmark
 act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route
 cls_fw sch_hfsc sch_ingress ledtrig_usbdev ip6t_REJECT ip6table_raw
 ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6
 nf_defrag_ipv6 ifb ipv6 eeprom_93cx6 arc4 crypto_blkcipher
 ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
 mii
 [  429.77] Process khubd (pid: 292, threadinfo=87b0c000,
 task=878ad770, tls=)
 [  429.77] Stack : 85cc93a0 86f69350   87b0dcd8
 87b0dcd8 00100100 00200200
 [  429.77]  86948000 85cc8ae0 85cc9460 86b9fa20 86f69350 
  86e80fac
 [  429.77]  0004 85cc8ae0 85cc9460 86b9fa20 85cc8ae0 86e14ddc
 87b0dd1c 87b0bbd0
 [  429.77]  86b9fa20 86948000 86b9fa20 86948000 86b9fa00 87b2c580
 879ff000 800def9c
 [  429.77]  87b39180 80131108 86b9fa20 86f69350 87b39180 879ff000
 86b9fa00 8008d734
 [  429.77]  ...
 [  429.77] Call Trace:
 [  429.77] [86e93018] ieee80211_remove_interfaces+0x128/0x1b4 [mac80211]
 [  429.77] [86e80fac] ieee80211_unregister_hw+0x3c/0xe4 [mac80211]
 [  429.77] [86e14ddc] rtl_usb_disconnect+0x4c/0xf4 [rtl_usb]
 [  429.77] [87b2c580] usb_deregister+0x228/0x2ec [usbcore]
 [  429.77] [8008d734] __device_release_driver+0x6c/0xd0
 [  429.77] [80117f64] device_release_driver+0x28/0x40
 [  429.77] [800edffc] bus_remove_device+0xec/0x120
 [  429.77] [801176fc] device_del+0x110/0x170
 [  429.77] [87b2ad58] usb_disable_device+0xb0/0x1d8 [usbcore]
 [  429.77] [87b22920] usb_disconnect+0xac/0x408 [usbcore]
 [  429.77] [87b24a68] usb_reset_device+0xd28/0x15c8 [usbcore]
 [  429.77] [80121c0c] do_exit+0x72c/0x744
 [  429.77]
 [  429.77]
 [  429.77] Code: 27a40018  8fa2001c  8fa30018 ac620004 ac43
 8fb00010  3c030010  3c020020  24630100
 [  430.11] ---[ end trace 6ca2573cb8fc44d5 ]---


I did some more looking into and testing of this kernel panic and it
is fixed by the following commit
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/net/mac80211/iface.c?id=87757a917b0b3c0787e0563c679762152be81312.
This commit is included in 3.10-stable and the latest compat-wireless,
but not in the current compat-wireless (22-5-2014) used by OpenWRT. So
the problem is already solved, sorry

ar71xx: Problems with USB WIFI dongles

2014-08-09 Thread Kristian Evensen

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 idea is to use the two on-board wifis as AP (I
want both 2.4 GHz and 5Ghz), and then use a USB wifi dongle for the
WAN connection. I run OpenWRT and the most recent kernel available
(3.14.12). The problems were also present on 3.10 kernels.

When configuring this setup, two problems occur:

1) I have tested with several different USB wifi dongles, some using
Realtek chipset (rl8192cu driver) and others using Atheros chipset
(ath9k_htc driver). The WDR4300 on-board wifi is also Atheros (ath9k
driver), and when I use a device from a different family (i.e., the
Realtek-dongles), the wifi authentication always times out. If I
disable the on-board wifi, the Realtek dongle works as expected
(connection to WAN wifi can be established). Is there a known problem
mixing different Wifi drivers on the ar71xx-platform/WDR4300, or am I
doing something wrong?

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.
The kernel oops looks like the following (the crash happens at the
same place independent of device):

[  429.73] usb 1-1.1.5.4: USB disconnect, device number 10
[  429.76] CPU 0 Unable to handle kernel paging request at virtual
address 00100104, epc == 86e93018, ra == 86e93010
[  429.77] Oops[#1]:
[  429.77] CPU: 0 PID: 292 Comm: khubd Not tainted 3.14.12 #4
[  429.77] task: 878ad770 ti: 87b0c000 task.ti: 87b0c000
[  429.77] $ 0   :   00200200 00100100
[  429.77] $ 4   : 87b0dce0 87b0dee0 8035 0008
[  429.77] $ 8   : 00090040 86a6a080 0020 00090040
[  429.77] $12   : 0013 000e 0007 0001
[  429.77] $16   : 85cc91a0 87b0dcd8 00100100 85cc91a8
[  429.77] $20   : 85cc91a0 00200200 86948000 87b41838
[  429.77] $24   : 80327df0 8010fe04
[  429.77] $28   : 87b0c000 87b0dcc8  86e93010
[  429.77] Hi: 0350
[  429.77] Lo: 0006
[  429.77] epc   : 86e93018
ieee80211_remove_interfaces+0x128/0x1b4 [mac80211]
[  429.77] Not tainted
[  429.77] ra: 86e93010
ieee80211_remove_interfaces+0x120/0x1b4 [mac80211]
[  429.77] Status: 1100dc03 KERNEL EXL IE
[  429.77] Cause : 008c
[  429.77] BadVA : 00100104
[  429.77] PrId  : 0001974c (MIPS 74Kc)
[  429.77] Modules linked in: ath9k rtl8192se rtl8192de rtl8192cu
rtl8192ce ath9k_htc ath9k_common rtl_usb rtl_pci pppoe ppp_async
option iptable_nat ath9k_hw ath usb_wwan smsc95xx rtlwifi rtl8187
rt73usb rt2x00usb rt2x00lib rndis_host qmi_wwan pppox ppp_generic
nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE huawei_cdc_ncm
cfg80211 cdc_ncm cdc_ether ax88179_178a asix xt_time xt_tcpudp
xt_tcpmss xt_string xt_statistic xt_state xt_recent xt_quota
xt_pkttype xt_owner xt_nfacct xt_nat xt_multiport xt_mark xt_mac
xt_limit xt_length xt_id xt_hl xt_helper xt_ecn xt_dscp xt_conntrack
xt_connmark xt_connlimit xt_connbytes xt_comment xt_addrtype xt_TCPMSS
xt_REDIRECT xt_NFQUEUE xt_LOG xt_HL xt_DSCP xt_CT xt_CLASSIFY
usbserial usbnet ts_kmp ts_fsm ts_bm slhc rtl8192c_common
nfnetlink_queue nfnetlink_acct nf_nat_irc nf_nat_ftp nf_nat
nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw
iptable_mangle iptable_filter ipt_REJECT ipt_ECN ipheth ip_tables
crc16 crc_itu_t crc_ccitt compat cdc_wdm cdc_acm act_connmark
act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route
cls_fw sch_hfsc sch_ingress ledtrig_usbdev ip6t_REJECT ip6table_raw
ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6
nf_defrag_ipv6 ifb ipv6 eeprom_93cx6 arc4 crypto_blkcipher
ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
mii
[  429.77] Process khubd (pid: 292, threadinfo=87b0c000,
task=878ad770, tls=)
[  429.77] Stack : 85cc93a0 86f69350   87b0dcd8
87b0dcd8 00100100 00200200
[  429.77]  86948000 85cc8ae0 85cc9460 86b9fa20 86f69350 
 86e80fac
[  429.77]  0004 85cc8ae0 85cc9460 86b9fa20 85cc8ae0 86e14ddc
87b0dd1c 87b0bbd0
[  429.77]  86b9fa20 86948000 86b9fa20 86948000 86b9fa00 87b2c580
879ff000 800def9c
[  429.77]  87b39180 80131108 86b9fa20 86f69350 87b39180 879ff000
86b9fa00 8008d734
[  429.77]  ...
[  429.77] Call Trace:
[  429.77] [86e93018] ieee80211_remove_interfaces+0x128/0x1b4 [mac80211]
[  429.77] [86e80fac] ieee80211_unregister_hw+0x3c/0xe4 [mac80211]
[  429.77] [86e14ddc] rtl_usb_disconnect+0x4c/0xf4 [rtl_usb]
[  429.77] [87b2c580] usb_deregister+0x228/0x2ec [usbcore]
[  429.77] [8008d734] __device_release_driver+0x6c/0xd0
[  429.77] [80117f64]

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

2014-01-21 Thread Kristian Evensen

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 can reliably
trigger it by sending AT+ZSNT=1,0,0 to the modem or setting system
selection to 0x0004 (both locking MF821D to 2G).
- The root cause is the modem, but I can trigger the error on
different USB hosts. I have been able to replicate it on the earlier
mention router, my two laptops (with Intel-chipsets), a Raspberry Pi
and some commercial mobile broadband routers. However, some hosts seem
more resilliant than others. One for example the TP-Link I can trigger
it all the time, while on my laptop it is more seldom.
- One theory that we have not been able to verify is that the problem
is somehow related to ISP. I got some friends in another country to
try the AT-command with MF821D and the TP-Link WDR4300, and they did
not see it.
- I tried the same with another modem I have, the Huawei E392. I had
no problems locking to 2G or moving between 3G/2G.
- Our current work-around is to disable 2G. After doing this we have
not seen this problem.

-Kristian
--
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

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

2013-12-03 Thread Kristian Evensen

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 mobile broadband performance, of both HSDPA and LTE,
and the modem we are currently working with is the ZTE MF821D (QMI).
The reason is that this is the modem used the two biggest operators
and it exports the information we need.

We are currently facing a USB problem that we have not been able to
solve. A USB ACK is not sent and the following messages appear in the
kernel logs:
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: nonzero urb status received: -71
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: wdm_int_callback - 0 bytes

This can go on for several minutes, during which USB is
non-responding. After this time period has passed, USB starts
responding again, the modems disconnect/connect and work again.
Initially we suspected a bug in the USB hub on the SoC, but after some
great help from Alan Stern that seems not to be the case. A summary of
our initial observations can be found here:
http://thread.gmane.org/gmane.linux.usb.general/99142

Instead, it seems like the issue is caused by the modem. The common
behavior is that the modem is moved into areas where there is no data
coverage (LED turns red), but it does not loose packet service. When
it gets service again (LED turns blue/green), the error occurs. The
following then appears in the log file (along with the
XactErr-messages described in my other email):

[ 2185.29] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71
[ 2185.29] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes
[ 2185.47] qmi_wwan 1-1.1.2:1.4: nonzero urb status received: -71
[ 2185.47] qmi_wwan 1-1.1.2:1.4: wdm_int_callback - 0 bytes
[ 2185.50] qmi_wwan 1-1.1.3:1.4: nonzero urb status received: -71
[ 2185.50] qmi_wwan 1-1.1.3:1.4: wdm_int_callback - 0 bytes
[ 2185.59] qmi_wwan 1-1.1.2:1.4: Error in flush path: -71
[ 2185.60] qmi_wwan 1-1.1.3:1.4: Error in flush path: -71

In order to get the Error in flush path, we first had to remove the
option module. Otherwise, we would only see (in addition to
wdm_int_callback + nonzero urb):
[62979.28] option1 ttyUSB7: option_instat_callback: error -71

We are currently a bit stomped and unsure how to progress. Our
qmi-dialer is exited and lsof shows that no applications have the
wdm-device open. We have tested with modems with different chipsets
(older Huawei 3G modems), and they do not display this issue, so it
seems to be a modem or chipset issue. We ran some tests with a ZTE
MF823D WebUI (also based on MDM9200) modem and saw some strange
behavior with it as well.

My question is, has anyone seen this behavior or have any hints as to
how we can progress? I implemented a quick hack in which I reduced the
number of retransmissions of a USB packet to a driver, in order to
shorten the time until USB becomes responsive again. It works, but it
is not very nice and seems to cause problems elsewhere.

Thanks in advance for any help,
Kristian
--
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

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

2013-12-03 Thread Kristian Evensen

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 suspected, thank you very much for letting me know.
Then I guess we have to live with some work-arounds. One interesting
observation is that the modem seems to reboot by itself and works just
fine once the USB queue (probably not the correct name) has been
flushed, so we will try to speed up the flush when packets with status
-71 arrives. I guess this will be a special case solution and not
something that should be submitted as a patch to the kernel.

Thanks again for the help,
Kristian
--
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

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

2013-12-03 Thread Kristian Evensen

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 this issue, or if it is possible to
disable this mode?

-Kristian
--
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

Re: USB instabilities with Atheros AR9344

2013-12-01 Thread Kristian Evensen

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 were sent to the modem).

 On the other hand, it is true that in some circumstances, problems in
 the hub could mess up communications between the host and the modem.
 This could happen if the hub communicates at high speed (480 Mb/s) and
 the modem communicates at full speed (12 Mb/s).

Thanks for this pointer. It turns out there was one detail I had
completely overlooked. Even though I used different modems, they are
all based on the same chipset (Qualcomm's MDM9200). Since I did not
see this issue on with another SoC, I doubt it is a chipset-issue, but
it is worth investigating. Both modems and hub are high-speed (and
they are enumerated as high-speed), so that part should be fine.

Thanks again,
Kristian
--
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

USB instabilities with Atheros AR9344

2013-11-29 Thread Kristian Evensen

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 experienced a USB problem that
we have not been able to solve. The USB hub works fine most of the
time, but when event X happens, USB becomes unusable for extended
periods of time. We have to disable/enable the power on the USB port
(using GPIO) and then wait until a timeout expires/queue is flushed.

The devices we have been able to trigger event X with is different
3G/LTE modems. We have not been able to figure out exactly what
triggers the event, but it happens when we move into areas with poor
or no coverage and then move back into coverage. We see the error both
with QMI-modems (qmi_wwan driver), AT-modems (option_serial driver)
and WebUI-modems (cdc_ether driver). When looking in dmesg after this
event has happened, the following messages appear based on the modem
type:

QMI:
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: nonzero urb status received: -71
Thu Nov 21 09:44:53 2013 kern.err kernel: [  490.60] qmi_wwan
1-1.1.2:1.4: wdm_int_callback - 0 bytes

Serial:
[62979.28] option1 ttyUSB7: option_instat_callback: error -71

WebUI:
[ 1192.68] hub 1-1:1.0: cannot reset port 1 (err = -71)
[ 1192.69] hub 1-1:1.0: Cannot enable port 1.  Maybe the USB cable is bad?

The common denominator seems to be the -71 error code, which is a
generic Protocol Error if I have understood correctly. When I search
for this error code, it seems that most problems have been due to
power. However, this seems not be the issue here. The modems are
connected to an active hub and event X happens with only a single
modem connected, so it seems unlikely that it is power.

In order to rule out the TP-Link router, we have also tested with
another router based on the same SoC (Netgear WNDR4300). The same
issue is seen. We also made some tests on a device with a different
SoC (Raspberry Pi, BCM2835) and do not see this issue.

We have mostly focused on the QMI modems and when using dynamic
debugging, dmesg also contains these errors (repeated many times):
[ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/1514 retry 26
[ 1911.20] ehci-platform ehci-platform: detected XactErr len 0/64 retry 14

Each packet is, as expected, retried 32 times. The data we sent when
these messages appeared was normal TCP traffic, which explains the
packet sizes. If we leave the router alone long enough, it is able to
restart the modems (they disconnect and then connect). However, this
can take many minutes (I guess the packet queue has to be flushed?),
and while this happens the USB hub is blocked (no traffic can pass
through it).

When running usbmon, we see the following around the time of the crash
(with QMI modem):

86abea80 1428742032 S Bi:1:115:7 -150 1514 
86abeb00 1428801536 C Bi:1:115:7 0 226 = 024b322c fd930250 f300
08004500 00d4bba7 4000fd06 08728027 245d2e0f
86abeb00 1428801554 S Bi:1:115:7 -150 1514 
84895c00 1428802518 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93
08004500 00349c42 40003f06 e6772e0f e6768027
84895c00 1428802660 C Bo:1:115:5 0 66 
86abeb80 1428982112 C Bi:1:115:7 0 1354 = 024b322c fd930250 f300
08004500 053cbbaa 4000fd06 04078027 245d2e0f
86abeb80 1428982141 S Bi:1:115:7 -150 1514 
86abec00 1429021624 C Bi:1:115:7 0 226 = 024b322c fd930250 f300
08004500 00d4bbab 4000fd06 086e8027 245d2e0f
86abec00 1429021653 S Bi:1:115:7 -150 1514 
84895480 1429022660 S Bo:1:115:5 -150 66 = 0250f300 024b 322cfd93
08004500 00349c43 40003f06 e6762e0f e6768027
84895480 1429022746 C Bo:1:115:5 0 66 
86b1dc00 1430690752 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1430690765 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1430690787 S Ii:1:115:6 -150:16 64 
86b03d80 1430691369 C Ci:1:115:0 0 39 = 01260080 03010400 0024001a
001e0400 9f0c 1d0200db 0e110200 01050106
86abec80 1430896349 C Bi:1:115:7 -71 0
84895800 1431014639 S Bi:1:115:7 -150 1514 
86abed00 1431066817 C Bi:1:115:7 -71 0
84895480 1431184603 S Bi:1:115:7 -150 1514 
86abed80 1431307124 C Bi:1:115:7 -71 0
86b03c00 1431330567 S Co:1:115:0 s 21 00  0004 0012 18 = 0111
0301 0125 00100200 ff00
86b03c00 1431331498 C Co:1:115:0 0 18 
86b1dc00 1431332988 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1431332996 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1431333012 S Ii:1:115:6 -150:16 64 
86b03d80 1431333484 C Ci:1:115:0 0 58 = 01390080 03010200 0120002d
00020400  01020092 05110400 01006e05
86b03c00 1431346879 S Co:1:115:0 s 21 00  0004 000d 13 = 010c
0301 004d 00
86b03c00 1431347879 C Co:1:115:0 0 13 
86b1dc00 1431348994 C Ii:1:115:6 0:16 8 = a101 0400
86b03d80 1431349002 S Ci:1:115:0 s a1 01  0004 1000 4096 
86b1dc00 1431349021 S Ii:1:115:6 -150:16

Re: USB instabilities with Atheros AR9344

2013-11-29 Thread Kristian Evensen

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 firmware (it can also be caused by unplugging
 the USB cable, but obviously that didn't happen here).  Ideally, if you
 knew what caused the device to go into this buggy state, you could
 avoid the situation.

Thanks for the pointer. I have to admit I am a little bit unsure about
what you refer to by device, do you mean the modem or the SoC USB hub?
As it seems like most of the retransmitted packets are the big ones
(1514 bytes), I guess it is the hub that does not ACK?

 It would not help.  Once the device stops replying to the host, it
 pretty much doesn't matter what you do on the host.  The only way to
 address the problem is to do some sort of error recovery on the device.

One interesting observations is that the modems seems to work fine
after this happens. They reattach to the network, switch between
UMTS/LTE and so forth.

 You could try doing a USB reset of the device.  Of course, this is
 likely to cause the device to lose all its settings, so it may end up
 being worse than the original problem.

Thanks, this is what we are currently experimenting with. Since it
seems to be a bug in the device, we made a quick hack where we monitor
the output from the kernel and reset USB as soon as -71 is seen. We
have also patched the qh_completions()-functions to drop packets where
qtd-length - QTD_LENGTH(token) == 0, to shorten the wait for the usb
reset to be detected. After a reset, the USB hub + modems work fine.

One thing I have noticed is that when this error occurs with
option_serial, a usb reset (by using gpio) is detected immediately.
This is not the case with qmi-modems, which use cdc_wdm, they hang
until packets on the queue have been retransmitted (and we have
disconnected the devices). Is this expected behavior?

Thanks again for the help!

-Kristian
--
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

43 matches

Mail list logo