Ben Hutchings writes:
> On Tue, 2017-07-11 at 17:21 +0200, Enrico Mioso wrote:
>> From: Enrico Mioso
>>
>> commit 2b02c20ce0c28974b44e69a2e2f5ddc6a470ad6f upstream.
> [...]
>> --- a/drivers/net/usb/cdc_ncm.c
>> +++ b/drivers/net/usb/cdc_ncm.c
>> @@ -724,8 +724,10 @@ int cdc_ncm_bind_common(struc
erface is configured as-such, it seems certain
> parts of the network stack expects a "good" value in skb->mac_header.
Thanks. Yes, I see that the tun driver also does this.
Acked-by: Bjørn Mork
And his should probably go to stable as well? with a
Fixes: 32f7adf633b9 ("net: qmi_wwan: support "raw IP" mode")
Setting dev->hard_mtu to 0 will cause a divide error in
usbnet_probe. Protect against devices with bogus CDC Ethernet
functional descriptors by ignoring a zero wMaxSegmentSize.
Signed-off-by: Bjørn Mork
---
I believe the problem found by syzcaller in qmi_wwan also applies
to cdc_ether.
based WWAN
devices")
Reported-by: Andrey Konovalov
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8c3733608271..a4f229edcceb 100644
--- a/drivers/net/usb/
Andrey Konovalov writes:
> Hi!
>
> I've got the following report while fuzzing the kernel with syzkaller.
Thanks. It would have helped a lot of you said *what* you were fuzzing,
though But based on where the bug is, I assume it is USB
descriptors?
> On commit 39dae59d66acd86d1de24294bd2f3
Did you read drivers/staging/irda/TODO ?
There is no need to answer that. You already have. Thanks a lot for
your ever lasting invaluable contributions to /dev/null. Please
continue.
Bjørn
such device
until we've actually seen one.
This is just my opinion, and probably full of bogus assumptions as
usual. I was sort of hoping that some expert would speak up so I didn't
have to :-)
But FWIW:
Reviewed-by: Bjørn Mork
Bjørn
Douglas Anderson writes:
> Every once in a while when my system is under a bit of stress I see
> some spammy messages show up in my logs that say:
>
> kevent X may have been dropped
>
> As far as I can tell these messages aren't terribly useful.
I agree, FWIW. These messages just confuse users
Douglas Anderson writes:
> If rx_submit() returns an error code then nobody calls usb_free_urb().
> That means it's leaked.
Nope. rx_submit() will call usb_free_urb() before returning an error:
static int rx_submit (struct usbnet *dev, struct urb *urb, gfp_t flags)
..
if (!skb) {
Anna-Maria Gleixner writes:
> From: Thomas Gleixner
>
> The bh tasklet is used in invoke the hrtimer (cdc_ncm_tx_timer_cb) in
> softirq context. This can be also achieved without the tasklet but with
> CLOCK_MONOTONIC_SOFT as hrtimer base.
>
> Signed-off-by: Thomas Gleixner
> Signed-off-by: Ann
disconnect+0x87/0xc0 [qmi_wwan]
? usb_unbind_interface+0x71/0x270 [usbcore]
? device_release_driver_internal+0x154/0x210
Reported-and-tested-by: Nathaniel Roach
Fixes: c6adf77953bc ("net: usb: qmi_wwan: add qmap mux protocol support")
Cc: Daniele Palmas
Signed-off-by: Bjørn Mork
Bjorn Andersson writes:
> This series starts by moving the common definitions of the QMUX protocol to
> the
> uapi header, as they are shared with clients - both in kernel and userspace.
>
> This series then introduces in-kernel helper functions for aiding the handling
> of QMI encoded messages
? device_release_driver_internal+0x154/0x210
? qmi_wwan_unbind+0x6d/0xc0 [qmi_wwan]
? usbnet_disconnect+0x6c/0xf0 [usbnet]
? qmi_wwan_disconnect+0x87/0xc0 [qmi_wwan]
? usb_unbind_interface+0x71/0x270 [usbcore]
? device_release_driver_internal+0x154/0x210
Reported-by: Nathaniel Roach
Fi
Oliver Neukum writes:
> Am Dienstag, den 11.07.2017, 17:21 +0200 schrieb Enrico Mioso:
>> Some firmwares in Huawei E3372H devices have been observed to switch back
>> to NTB 32-bit format after altsetting switch.
>> This patch implements a driver flag to check for the device settings and
>> set NT
"Baxter, Jim" writes:
> I tested this with printk's to show when the low memory code was triggered
> and the value of ctx->tx_low_mem_val and ctx->tx_low_mem_max_cnt.
> I created a workqueue that slowly used up the atomic memory until the
> code is triggered.
>
> I could add debug prints, though
er
allocation has failed. Maybe add some sort of debug helper(s) in a
followup patch? How did you verify the patch operation while testing it?
Anyway, that's no show stopper of course. So FWIW:
Reviewed-by: Bjørn Mork
Jay Vosburgh writes:
> Michael J Dilmore wrote:
>
>>if (WARN_ON(!new_active_slave) {
>>netdev_dbg("Can't add new active slave - pointer null");
>>return ERROR_CODE
>>}
>
> In general, yes, but in this case, the condition should be
> impossible to hit, so BUG_ON seems appropriate.
I
Johannes Berg writes:
> From: Johannes Berg
>
> It seems like a historic accident that these return unsigned char *,
> and in many places that means casts are required, more often than not.
>
> Make these functions (skb_put, __skb_put and pskb_put) return void *
> and remove all the casts across
A new Sierra Wireless EM7305 device ID used in a Toshiba laptop,
and two Longcheer device IDs entries used by Telewell TW-3G HSPA+
branded modems.
Reported-by: Petr Kloc
Reported-by: Teemu Likonen
Signed-off-by: Bjørn Mork
---
The following patch should be backported to v4.9 and later stable
Chenbo Feng writes:
> This patch is still under working since it may have problem with
> ip_fragment() call, did you applied it already? Should I send a revert
> patch to you then?
It does? I initially thought so too, but looking closer I believe the
ip6_copy_metadata() calls in ip6_fragment() t
David Laight writes:
> From: linux-usb-ow...@vger.kernel.org
> [mailto:linux-usb-ow...@vger.kernel.org] On Behalf Of Jim Baxter
>> Sent: 16 May 2017 18:41
>>
>> The CDC-NCM driver can require large amounts of memory to create
>> skb's and this can be a problem when the memory becomes fragmented
Oliver Neukum writes:
> @@ -472,7 +489,6 @@ static void usbnet_cdc_zte_status(struct usbnet *dev,
> struct urb *urb)
>
> if (urb->actual_length < sizeof(*event))
> return;
> -
> event = urb->transfer_buffer;
>
> if (event->bNotificationType != USB_CDC_NOTIFY_N
Oliver Neukum writes:
> @@ -417,7 +434,7 @@ int usbnet_cdc_bind(struct usbnet *dev, struct
> usb_interface *intf)
> BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data)
> < sizeof(struct cdc_state)));
>
> - status = usbnet_generic_cdc_bind(dev, intf);
> + status
In their infinite wisdom, and never ending quest for end user frustration,
Lenovo has decided to use a new USB device ID for the wwan modules in
their 2017 laptops. The actual hardware is still the Sierra Wireless
EM7455 or EM7430, depending on region.
Signed-off-by: Bjørn Mork
---
drivers/net
Jim Baxter writes:
> The CDC-NCM driver can require large amounts of memory to create
> skb's and this can be a problem when the memory becomes fragmented.
>
> This especially affects embedded systems that have constrained
> resources but wish to maximise the throughput of CDC-NCM with 16KiB
> NT
Oliver Neukum writes:
> RNDIS does not do multicast filtering and the commands crash a few devices.
> Make it conditional.
Strange. I thought we already discussed this when the filter reset
request was initially added 3 years ago. Ref
https://patchwork.ozlabs.org/patch/374137/
Bjørn
Daniele Palmas writes:
> This patch adds support for Telit ME910 PID 0x1100.
>
> Signed-off-by: Daniele Palmas
Acked-by: Bjørn Mork
David, please add this to your stable queue as well. Thanks
Bjørn
Daniele Palmas writes:
> So, I applied your debug patch and this is what is happening:
Thanks
> [ 4306.730786] wdm_open: qmi_wwan 2-2:1.2: draining queued data
> [ 4306.730955] wdm_write: qmi_wwan 2-2:1.2: Tx URB has been submitted index=2
>
> Here qmicli is stuck. Then I disconnect the cable:
Aleksander Morgado writes:
> I'm just running --dms-get-operating-mode multiple times, and getting
> errors frequently:
Could you retry that with cdc-wdm debugging enabled (e.g.
"echo 'module cdc_wdm +fp' > /sys/kernel/debug/dynamic_debug/control")
and something like this:
diff --git a/drivers
Aleksander Morgado writes:
> On Wed, Apr 19, 2017 at 7:28 PM, Bjørn Mork wrote:
>>> as a side note in latest kernels I had troubles with qmi devices
>>> (e.g. I/O error when using qmicli).
>>>
>>> I found your suggestion
Daniele Palmas writes:
> as a side note in latest kernels I had troubles with qmi devices
> (e.g. I/O error when using qmicli).
>
> I found your suggestion in libqmi mailing list to revert commit
>
> 833415a3e781a26fe480a34d45086bdb4fe1e4c0
> cdc-wdm: fix "out-of-sync" due to missing notification
/linux/usb/usbnet.h| 4 +++
> 18 files changed, 73 insertions(+), 4 deletions(-)
>
> v2: EXPORT usbnet_get_stats64()
> rebase on top of net-next
>
> v3: use percpu vars for stats64 counters
>
> v4: update all usbnet drivers to use stats64
Looking good. For the qmi_wwan part:
Acked-by: Bjørn Mork
On March 31, 2017 3:27:59 PM CEST, Greg Ungerer wrote:
>On 31/03/17 18:48, Bjørn Mork wrote:
>
>>> +void usbnet_get_stats64(struct net_device *net, struct
>rtnl_link_stats64 *stats)
>>> +{
>>> + struct usbnet *dev = netdev_priv(net);
>>
Greg Ungerer writes:
> Add support for the net stats64 counters to the usbnet core and then to
> the qmi_wwan driver.
>
> This is a strait forward addition of 64bit counters for RX and TX packets
> and byte counts. It is done in the same style as for the other net drivers
> that support stats64.
Greg Ungerer writes:
> Add support for the net stats64 counters to the usbnet core and then to
> the qmi_wwan driver.
>
> This is a strait forward addition of 64bit counters for RX and TX packets
> and byte counts. It is done in the same style as for the other net drivers
> that support stats64.
Tony Lindgren writes:
> * Bjørn Mork [170319 09:33]:
>> Tony Lindgren writes:
>>
>> > This gets qmicli working with the MDM6600 modem.
>> >
>> > Cc: Bjørn Mork
>> > Reviewed-by: Sebastian Reichel
>> > Tested-by: Sebastian Reichel
&
Tony Lindgren writes:
> This gets qmicli working with the MDM6600 modem.
>
> Cc: Bjørn Mork
> Reviewed-by: Sebastian Reichel
> Tested-by: Sebastian Reichel
> Signed-off-by: Tony Lindgren
> ---
> drivers/net/usb/qmi_wwan.c | 4
> 1 file changed, 4 insertions(
This is a Dell branded Sierra Wireless EM7455. It is operating in
MBIM mode by default, but can be configured to provide two QMI/RMNET
functions.
Signed-off-by: Bjørn Mork
---
Note regarding stable backports:
This device should only be added to v4.5 and later. It depends on
commit 32f7adf633b9
Yasuaki Ishimatsu writes:
> The fjes driver is used only by FUJITSU servers and almost of all
> servers in the world never use it. But currently if ACPI PNP0C02
> is defined in the ACPI table, the following message is always shown:
>
> "FUJITSU Extended Socket Network Device Driver - version 1.2
Bjørn Mork writes:
> This is new with v4.11-rc1, so I strongly suspect commit 7e54d9d063fa
> ("e1000e: driver trying to free already-free irq"), which looks more
> than suspicious in this context. Haven't had time to test a revert
> yet. Just wanted to give an a
This is new with v4.11-rc1, so I strongly suspect commit 7e54d9d063fa
("e1000e: driver trying to free already-free irq"), which looks more
than suspicious in this context. Haven't had time to test a revert
yet. Just wanted to give an advance warning in case this isn't known.
Suspending and resu
n this makes sense. But I think it might be worth a note
about what we replace here and why, in case you happen to know that...
I realise that this is inherited from the original driver.
Just minor nits. Overall this looks very good to me, FWIW.
Reviewed-by: Bjørn Mork
Bjørn
card")
Cc: Dan Williams
Signed-off-by: Bjørn Mork
---
Resending with correct author and to address. I didn't manage to spell
kernel correctly... I guess I should have had one more cup of coffee
this morning.
No changes to the diff.
drivers/net/usb/cdc_ether.c | 8
drivers/net
peter green writes:
> Disabling privacy extensions solved the issue but obviously reveals
> the MAC address of my new machine to the world which is undesirable.
I have no solution to the problem with privacy extensions, but just
wanted to let you know there is a third alternative for IPv6
autoco
>
> Signed-off-by: Daniele Palmas
Thanks. This looks as nice as we can possibly do for now. I am happy
to add
Reviewed-by: Bjørn Mork
This patch also helped me understanding the problem you face even
better: It's not the "set_altsetting 0" that's causing problems, bu
Daniele Palmas writes:
> I went back to this and further checking revealed that MBIM function
> reset is not needed and the only problem is related to commit
> 48906f62c96cc2cd35753e59310cb70eb08cc6a5 cdc_ncm: toggle altsetting to
> force reset before setup, that, however, is mandatory for some H
Daniele Palmas writes:
> This patch adds support for PID 0x1040 of Telit LE922A.
LGTM
Acked-by: Bjørn Mork
Kristian Evensen 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->bNotificationT
Bjørn Mork writes:
> Finally, I found my modems (or at least a number of them) again today.
> But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
> giving us a hard time. It does not work with your patch. The symptom is
> the same as earlier: The modem re
Finally, I found my modems (or at least a number of them) again today.
But I'm sorry to say, that the troublesome Huawei E3372h-153 is still
giving us a hard time. It does not work with your patch. The symptom is
the same as earlier: The modem returns MBIM frames with 32bit headers.
So for now,
Jussi Peltola writes:
> So here's another stab. The comments and the current implementation are
> not in sync: any non-multicast address starting with a null octet gets
> rewritten, while the comment specifically mentions 00:a0:c6:00:00:00. It
> is certainly not elegant but re-writing all unicast
Jussi Peltola writes:
> This brokenness appears reliably after running "rdisc6 wwan0" but I have
> not debugged if this is related to timing or the format of the router
> solicitation. Before receiving a router solicitation, v4 is received
> correctly and v6 does not work. After sending the MF821
Alan Stern writes:
> On Thu, 10 Nov 2016, Kai-Heng Feng wrote:
>
>> Is there a way to force XHCI run at HighSpeed?
>
> Yes, like I said above: Use a USB-2 cable instead of a USB-3 cable.
It's an m.2 form factor modem, so there most likely isn't any cable
involved. But the principle is the same:
Kai-Heng Feng writes:
> On Wed, Nov 9, 2016 at 8:32 PM, Bjørn Mork wrote:
>> Oliver Neukum writes:
>>
>>> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>>>
>>>> These problems could very well be caused by running at SuperSpeed
>>>
Oliver Neukum writes:
> On Tue, 2016-11-08 at 13:44 -0500, Alan Stern wrote:
>
>> These problems could very well be caused by running at SuperSpeed
>> (USB-3) instead of high speed (USB-2).
>>
>> Is there any way to test what happens when the device is attached to
>> the computer by a USB-2 cab
Alan Stern writes:
> On Tue, 8 Nov 2016, Kai-Heng Feng wrote:
>
>> Hi,
>>
>> On Mon, Nov 7, 2016 at 7:02 PM, Oliver Neukum wrote:
>> > On Fri, 2016-11-04 at 17:57 +0800, Kai-Heng Feng wrote:
>> >> Sometimes cdc_mbim failed to probe if runtime pm is enabled:
>> >> [9.305626] cdc_mbim: probe
e cannot enable this unconditionally for all older devices, and
there doesn't appear to be anything we can use in the USB descriptors
to identify these chips, we are forced to use a device specific quirk
flag.
Reported-and-tested-by: Sebastian Sjoholm
Signed-off-by: Bjørn Mork
---
driver
> ==From: Marek Brudka
..
> ==The bad thing is DHCP. It seems, that cdc_ncm driver somehow consumes DHCP
> ==replies. I had to manually setup wwan0 interface as well as routing
> ==using the result
> ==of Hayes command
> ==
> ==AT^DHCP?
> ==^DHCP:
> ==EC684764,F8FF,E9684764,E9684764,356002D4,3
Hayes Wang writes:
> Bjørn Mork [mailto:bj...@mork.no]
>> Sent: Thursday, September 08, 2016 3:55 PM
> [...]
>> Yes, I see that. But is that strictly necessary? Couldn't you just say:
>> "CDC ECM is supported by cdc_ether and therefore limited to the feature
Hayes Wang writes:
> Bjørn Mork [mailto:bj...@mork.no]
>> Sent: Wednesday, September 07, 2016 9:51 PM
> [...]
>> So this adds a lot of code to work around the issues you introduced by
>> unnecessarily blacklisting the CDC ECM configuration earlier, and still
>> mak
[ CCing Oliver, who AFAIK still is the cdc_ether maintainer and should
have the final word on this ]
Hayes Wang writes:
> Some people prefer to use ECM mode rather than vendor mode. Therefore, I add
> CONFIG_RTL8152_CONFIG_VALUE in Kconfig. Then, the users could choose the USB
> configuration
Oliver Neukum writes:
> Just return an error upon failure.
>
> Signed-off-by: Oliver Neukum
> ---
> drivers/net/usb/kaweth.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/net/usb/kaweth.c b/drivers/net/usb/kaweth.c
> index 37bf715..3cd6906 100644
> --- a/drivers/net/usb/kaw
Oliver Neukum writes:
> But why fix similar issues at two different places? And what about
> PCI or other cards that show the same problem?
I guess some sort of common helper would be nice to avoid open coding
this fix everywhere. But you would still have to modify every driver
where it is appl
Oliver Neukum writes:
> On Mon, 2016-07-18 at 16:10 +0200, Kristian Evensen wrote:
>> 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
>> > driv
David Laight writes:
> From: Bjørn Mork
>> Sent: 13 July 2016 23:23
> ...
>> Or how about the more generic?:
>>
>> if (bp[0] & 0x02)
>> eth_hw_addr_random(net);
>> else
>> ether_addr_copy(net->dev_a
Kristian Evensen writes:
> 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
> checkp
Hannes,
I just realized that I missed you on the CC list of the v2 patch. Sorry.
It was definitely not my intention. I really appreciate the feedback you
have kindly provided before.
I guess you might have seen it in netdev anyway, but in case not, here
is a direct patchwork link: http://patchwor
David Miller writes:
> What really irks me is that we "fixing" something without knowing what
> actually is the problem.
Agreed
> Someone needs to figure out exactly what is making the Juniper thing
> unhappy. It really shouldn't care if a link local address is assigned
> to the tun device, th
valdis.kletni...@vt.edu writes:
> Tested against next-20160708, and the Juniper code works fine. Feel free
> to stick a Tested-By: on the V2 patch...
Thanks to both of you for verifying that it solves the Juniper problem.
A tip: Patchworks is nice enough to automatically pick up tags from
review
s Kletnieks
Reported-by: Jonas Lippuner
Suggested-by: Hannes Frederic Sowa
Cc: 吉藤英明
Signed-off-by: Bjørn Mork
---
v2 changes:
- added a netdevice private flag to suppress automatic IPv6 LL
- suppressing only for "tun" devices
So, something like this? It has the bonus that it can be use
Hannes Frederic Sowa writes:
> On 09.07.2016 19:23, Bjørn Mork wrote:
>> Hannes Frederic Sowa writes:
>>> On Sat, Jul 9, 2016, at 23:13, Bjørn Mork wrote:
>>>> The Juniper SSL VPN client use a "tun" interface and seems to
>>>> be picky about vi
Hannes Frederic Sowa writes:
> On Sat, Jul 9, 2016, at 23:13, Bjørn Mork wrote:
>> The Juniper SSL VPN client use a "tun" interface and seems to
>> be picky about visible changes.to it. Commit cc9da6cc4f56
>> ("ipv6: addrconf: use stable address generator for A
ONE")
Reported-by: Valdis Kletnieks
Reported-and-tested-by: Jonas Lippuner
Cc: Hannes Frederic Sowa
Cc: 吉藤英明
Signed-off-by: Bjørn Mork
---
Valdis,
I know you reported this regression back in April, but I never
saw any answers to Hannes' and mine followup quesions so I forgot
all abou
Oliver Neukum writes:
> On Sun, 2016-07-03 at 22:24 +0200, Bjørn Mork wrote:
>> Several Lenovo users have reported problems with their Sierra
>> Wireless EM7455 modem. The driver has loaded successfully and
>> the MBIM management channel has appeared to work, includ
: Aleksander Morgado
Signed-off-by: Bjørn Mork
---
I hope this unconditional short sleep during probing is acceptable,
as I don't want to start a new non-maintainable quirk device list for
this. The EM7455 is already used by a number of laptop vendors, each
using their own device ID. More are l
writes:
>> > 2) Track whether this is the first or second USB NIC plugged in. Only
>> > offer it
>> on the first NIC detected by r8152. When the second NIC is plugged in don't
>> match from ACPI.
>> > There would be a question of what to do if the first NIC is removed and
>> added back if it s
writes:
>> > +static u8 amac_ascii_to_hex(int c)
>> > +{
>> > + if (c <= 0x39)
>> > + return (u8)(c - 0x30);
>> > + else if (c <= 0x46)
>> > + return (u8)(c - 0x37);
>> > + return (u8)(c - 0x57);
>> > +}
>>
>
> Sorry forgot to address this.
>
>> We really don't have such a
Greg KH writes:
> And finally, this seems odd overall given that a MAC address should be
> associated with the specific network device, not the overall system.
Definitely.
I wonder if this isn't a perfect candidate for an x86
arch_get_platform_mac_address() implementation? Then you could just
make it do anything useful
with my current test device. I am a bit curious about what your device
descriptor looks like if you actually hit this problem...
But your patch is a nice improvement in any case, so FWIW:
Revieved-by: Bjørn Mork
tl;dr
My quick test was done with an MBIM device hav
Valdis Kletnieks writes:
> I'll say up front - no, I do *not* have a clue why this commit causes this
> problem - it makes exactly zero fsking sense.
>
> Scenario: $WORK is blessed with a Juniper VPN system. I've been
> seeing for a while now (since Dec-ish) an issue where at startup,
> the tun
Timur Tabi writes:
> Shanker Donthineni wrote:
>> drivers/net/ethernet/qualcomm/emac/emac-mac.c: In function
>> 'emac_mac_up':
>>drivers/net/ethernet/qualcomm/emac/emac-mac.c:1076:9: warning:
>>large integer implicitly truncated to unsigned type [-Woverf
/ndp_to_end
Reported-by: Andreas Fett
Signed-off-by: Bjørn Mork
---
I'm requesting this for stable, but it depends on commit
f8c0cfa5eca9 ("net: cdc_mbim: add "NDP to end" quirk for Huawei E3372")
so it is only applicable to v4.3 (where the dependency is
backporte
Hannes Frederic Sowa writes:
> On Fri, Apr 8, 2016, at 16:18, Bjørn Mork wrote:
>> Daniel Borkmann writes:
>>
>> >
>> >if (!token)
>> >return -EINVAL;
>> > - if (ipv6_addr_any(token))
>> > - return
Daniel Borkmann writes:
>
> if (!token)
> return -EINVAL;
> - if (ipv6_addr_any(token))
> - return -EINVAL;
> if (dev->flags & (IFF_LOOPBACK | IFF_NOARP))
> return -EINVAL;
Not directly related to the patch in question. It just made me a
Robert Dobrowolski writes:
> From: Rafal Redzimski
>
> Current implementation updates the mtu size and notify cdc_ncm
> device using USB_CDC_SET_MAX_DATAGRAM_SIZE request about datagram
> size change instead of changing rx_urb_size.
>
> Whenever mtu is being changed, datagram size should also be
Alex writes:
> Apr 01 11:33:24 arch kernel: BUG: unable to handle kernel NULL pointer
> dereference at 0003
> Apr 01 11:33:24 arch kernel: IP: []
> usbnet_generic_cdc_bind+0x171/0x710 [cdc_ether]
..
> Apr 01 11:33:24 arch kernel: Call Trace:
> Apr 01 11:33:24 arch kernel: []
> gen
gt; Bjorn, can you take a quick look at this?
Looks fine to me.
Reviewed-by: Bjørn Mork
Bjørn
n
I: If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
I: If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
I: If#= 5 Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage"
Reported-by: Thomas Schäfer
Signed-off-by: Bjørn Mork
---
drivers/net/usb/q
ss 5806 Gobi(TM)
> 4G LTE Mobile Broadband Card */
> {QMI_FIXED_INTF(0x413c, 0x81a3, 8)},/* Dell Wireless 5570 HSPA+
> (42Mbps) Mobile Broadband Card */
> {QMI_FIXED_INTF(0x413c, 0x81a4, 8)},/* Dell Wireless 5570e HSPA+
> (42Mbps) Mobile Broadband Card */
Perfect. Thanks.
Acked-by: Bjørn Mork
Patrik Halfar writes:
> --- a/drivers/net/usb/qmi_wwan.c
> +++ b/drivers/net/usb/qmi_wwan.c
> @@ -884,6 +884,7 @@ static const struct usb_device_id products[] = {
> {QMI_FIXED_INTF(0x413c, 0x81a8, 8)},/* Dell Wireless 5808 Gobi(TM)
> 4G LTE Mobile Broadband Card */
> {QMI_FIXED_I
Schemmel Hans-Christoph writes:
> + {QMI_FIXED_INTF(0x1e2d, 0x0082, 4)},/* Cinterion PHxx,PXxx (2
> RmNet) */
That's broken. Sorry. You'll have to figure out some way submit this
in a form that can be applied using "git am".
There are some hints in
https://www.kernel.org/doc/Documenta
On March 16, 2016 8:35:26 AM CET, Schemmel Hans-Christoph
:
>
>If I digital sign the mail it should be send unmodified/without
>disclaimer.
>But there will be the smime.p7s attached to the mail - like in this
>mail.
>
>Would it be ok?
Fine with me as long as it applies cleanly without having
Schemmel Hans-Christoph writes:
> If you are not the intended recipient of this message, please delete it and
> notify the sender.
OK. Deleted.
Bjørn
Linus Torvalds writes:
> So looking at this, I wonder...
>
> Why is that FLAG_LINK_INTR thing not just always used?
>
> The _only_ thing that FLAG_LINK_INTR does is to cause
>
> usbnet_link_change(dev, 0, 0);
>
> to be called after network device attach. That doesn't seem to be
> controv
purpose.
Fixes: 8a34b0ae8778 ("usbnet: cdc_ncm: apply usbnet_link_change")
Reported-by: Andrey Konovalov
Suggested-by: Linus Torvalds
Signed-off-by: Bjørn Mork
---
David Miller writes:
> From: Andrey Konovalov
>
>> Could you also add:
>> Reported-by: Andrey Konovalov
On March 5, 2016 4:51:30 PM CET, Oliver Neukum wrote:
>On Fri, 2016-03-04 at 14:43 -0800, Linus Torvalds wrote:
>
>> So you have usbnet_defer_kevent() getting triggered, which in turn
>> ends up using "usbnet->kevent"
>>
>> But somebody like Oliver is really the right person to check this.
>For
fixes a setup problem observed on a number of Huawei devices,
appearing to operate in NTB-32 mode even if we explicitly set them
to NTB-16 mode.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/cdc_ncm.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/usb
The MC74xx and EM74xx modules use different IDs by default, according
to the Lenovo EM7455 driver for Windows.
Signed-off-by: Bjørn Mork
---
drivers/net/usb/qmi_wwan.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb
Alt= 0 #EPs= 2 Cls=08(stor.) Sub=06 Prot=50 Driver=usb-storage
Reported-by: Thomas Schäfer
Signed-off-by: Bjørn Mork
---
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 23e9880791fc..570deef53f74 100644
--
Sergei Shtylyov writes:
>dev_er(), maybe?
I like that!
It's often hard to know whether to print something or be quiet.
pr_er(), dev_er(), netdev_er() etc would be the perfect solution to that
problem.
Bjørn
101 - 200 of 275 matches
Mail list logo
