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
Hi,
On Wed, Nov 30, 2016 at 4:17 PM, Oliver Neukum 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 remov
"cdc_ether: Improve ZTE MF823/831/910 handling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
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
On Wed, Nov 30, 2016 at 10:51 PM, Bjørn Mork wrote:
> Kristian Evensen writes:
>
>> +void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
>> +{
>> + struct usb_cdc_notification *event;
>> +
>> + if (urb->actual_length &l
ling")
Reported-by: Henning Schild
Signed-off-by: Kristian Evensen
---
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 10064
From: Kristian Evensen
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
---
drivers/hid
From: Kristian Evensen
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
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
On Thu, Jul 14, 2016 at 9:54 AM, Kristian Evensen
wrote:
> 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);
>>
From: Kristian Evensen
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
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
---
drivers/net/usb/cdc_ether.c | 53
Hi,
On Mon, Jul 18, 2016 at 3:01 PM, Oliver Neukum 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
>
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
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 le
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 le
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 pr
Hi Lars,
On Tue, Jul 19, 2016 at 10:30 AM, Lars Melin 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
>> an
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
---
drivers/net/usb/cdc_ether.c | 60 +
1 f
On Tue, Jul 19, 2016 at 2:33 PM, Oliver Neukum 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;
>> }
>>
&g
evices (thanks Lars Melin).
Signed-off-by: Kristian Evensen
---
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/n
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
Acked-by: Oliver Neukum
---
drivers/net/usb/cdc_ether.c | 51 +
1 file changed, 51 insertions(+)
dif
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 experienc
Hi,
Thank you very much for the quick reply.
On Fri, Nov 29, 2013 at 4:13 PM, Alan Stern 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
Thank you very much for another detailed reply.
On Sat, Nov 30, 2013 at 4:55 PM, Alan Stern 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)
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 mo
Hei Bjørn,
On Tue, Dec 3, 2013 at 3:37 PM, Bjørn Mork 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, tha
Hi Markus,
On Tue, Dec 3, 2013 at 9:08 PM, Markus Gothe 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
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
From: Kristian Evensen
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
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 i
Hi all,
On Sat, Aug 9, 2014 at 12:03 PM, Kristian Evensen
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 kerne
or all ports
together. Commands 0x01-0x03 is used to power down ports 1-3, while 0x0A is used
to power down all ports. In order to power up a port (or all ports), the command
is OR'd with 0x10.
Signed-off-by: Kristian Evensen
---
drivers/hid/hid-core.c| 1 +
drivers/hid/hid-ids.
Hi,
On Mon, Jan 19, 2015 at 10:38 PM, Greg KH 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 u
On Mon, Jan 19, 2015 at 11:49 PM, Greg KH wrote:
> That would be great, send it to the hid maintainer and cc the list
> (using scripts/get_maintainer.pl should tell you the proper people to
> send it to.)
Thanks for the pointer. Will update the patch and submit a new one tonight.
> If you can ru
: Kristian Evensen
---
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
Hi,
On Tue, Mar 19, 2019 at 10:26 AM Johan Hovold wrote:
> I think we should keep both entries together, so reordered above.
Thanks!
> Now applied, but could you please post the output of usb-devices (with
> all interfaces enabled) for this device for reference?
Sure, here you go:
Bus 002 De
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 whe
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 lik
Hi,
On Tue, Oct 3, 2017 at 11:16 AM, Kristian Evensen
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
On Tue, Oct 3, 2017 at 4:51 PM, Kristian Evensen
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 no
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 pas
[ 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: Kris
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 l
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
---
drivers/usb/serial/option.c | 7 +++
1 file changed, 7 insertions
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 add
->v2:
* Updated commit prefix (thanks Johan Hovold)
* Updated commit message slightly.
Signed-off-by: Kristian Evensen
---
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 b6320e3be
ignore the device if
number of interfaces equals three (and subclass is set).
Signed-off-by: Kristian Evensen
---
drivers/usb/serial/option.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index
Hi,
On Mon, Sep 10, 2018 at 12:30 PM Johan Hovold wrote:
> Please provide the output of usb-devices (or lsusb -v) for both
> "configurations". How do you update the configuration by the way?
The configuration is updated using a proprietary AT-command
(AT+QCFG="usbcfg"). The format of the command
On Tue, Sep 11, 2018 at 4:00 PM Lars Melin wrote:
> This also becomes a mess for the qmi-wwan driver which has the rmnet/qmi
> interface hardcoded to 4 so that driver will also need a workaround.
> Quectel seems to have completely missed the reason why usb id's should
> be unique and not reused f
On Wed, Sep 12, 2018 at 6:32 PM Lars Melin wrote:
> You have chosen a platform which has limited usb resources and want to
> solve that problem by adjusting the device driver?
No, you asked for a good reason for why disabling and not just
ignoring an interface makes sense, and I think that suppor
Hi Johan,
On Thu, Sep 13, 2018 at 11:17 AM Johan Hovold wrote:
> Kristian would you mind giving it a try?
Yes, thank you very much. I will give the patches a go during the day
today and report back.
> Oh, also note that I dropped the RSVD(5) for the ADB interface in your
> patch since it uses a
Hello again,
On Thu, Sep 13, 2018 at 11:17 AM Johan Hovold wrote:
> Kristian would you mind giving it a try?
I just finished backporting + testing your patch with our 4.14-kernel
(mine is already there) and it works great. The driver correctly
handles different EP06-configurations.
Thanks a lot
Hi Johan,
On Fri, Sep 14, 2018 at 9:51 AM Johan Hovold wrote:
> Great, thanks for testing. Do you mind if I add your tested-by to the
> patch?
Not at all, go right ahead! I should probably have replied to the
patch with a Tested-by. Sorry about forgetting that.
BR,
Kristian
The Quectel EM12 is a Cat. 12 LTE modem. It behaves in the exactly the
same way as the EP06 (including the dynamic configuration behavior), so
the same checkes on reserved interfaces, etc. are needed.
Signed-off-by: Kristian Evensen
---
drivers/usb/serial/option.c | 4
1 file changed, 4
54 matches
Mail list logo
