linux-stable.git/drivers/net, branch v3.10.63 Linux kernel stable tree igb: bring link up when PHY is powered up 2014-12-16T17:09:43+00:00 Todd Fujinaka todd.fujinaka@intel.com 2014-06-17T06:58:11+00:00 e6a18c108e386866325b3b6e986f612ee512787c commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream. Call igb_setup_link() when the PHY is powered up. Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com> Reported-by: Jeff Westfahl <jeff.westfahl@ni.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Cc: Vincent Donnefort <vdonnefort@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit aec653c43b0c55667355e26d7de1236bda9fb4e3 upstream.

Call igb_setup_link() when the PHY is powered up.

Signed-off-by: Todd Fujinaka <todd.fujinaka@intel.com>
Reported-by: Jeff Westfahl <jeff.westfahl@ni.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: Vincent Donnefort <vdonnefort@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net: mvneta: fix Tx interrupt delay 2014-12-16T17:09:43+00:00 willy tarreau w@1wt.eu 2014-12-02T07:13:04+00:00 8df2d2d784394efd9ab16d8f05bdc49ce46ac32c [ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ] The mvneta driver sets the amount of Tx coalesce packets to 16 by default. Normally that does not cause any trouble since the driver uses a much larger Tx ring size (532 packets). But some sockets might run with very small buffers, much smaller than the equivalent of 16 packets. This is what ping is doing for example, by setting SNDBUF to 324 bytes rounded up to 2kB by the kernel. The problem is that there is no documented method to force a specific packet to emit an interrupt (eg: the last of the ring) nor is it possible to make the NIC emit an interrupt after a given delay. In this case, it causes trouble, because when ping sends packets over its raw socket, the few first packets leave the system, and the first 15 packets will be emitted without an IRQ being generated, so without the skbs being freed. And since the socket's buffer is small, there's no way to reach that amount of packets, and the ping ends up with "send: no buffer available" after sending 6 packets. Running with 3 instances of ping in parallel is enough to hide the problem, because with 6 packets per instance, that's 18 packets total, which is enough to grant a Tx interrupt before all are sent. The original driver in the LSP kernel worked around this design flaw by using a software timer to clean up the Tx descriptors. This timer was slow and caused terrible network performance on some Tx-bound workloads (such as routing) but was enough to make tools like ping work correctly. Instead here, we simply set the packet counts before interrupt to 1. This ensures that each packet sent will produce an interrupt. NAPI takes care of coalescing interrupts since the interrupt is disabled once generated. No measurable performance impact nor CPU usage were observed on small nor large packets, including when saturating the link on Tx, and this fixes tools like ping which rely on too small a send buffer. If one wants to increase this value for certain workloads where it is safe to do so, "ethtool -C $dev tx-frames" will override this default setting. This fix needs to be applied to stable kernels starting with 3.10. Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com> Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit aebea2ba0f7495e1a1c9ea5e753d146cb2f6b845 ]

The mvneta driver sets the amount of Tx coalesce packets to 16 by
default. Normally that does not cause any trouble since the driver
uses a much larger Tx ring size (532 packets). But some sockets
might run with very small buffers, much smaller than the equivalent
of 16 packets. This is what ping is doing for example, by setting
SNDBUF to 324 bytes rounded up to 2kB by the kernel.

The problem is that there is no documented method to force a specific
packet to emit an interrupt (eg: the last of the ring) nor is it
possible to make the NIC emit an interrupt after a given delay.

In this case, it causes trouble, because when ping sends packets over
its raw socket, the few first packets leave the system, and the first
15 packets will be emitted without an IRQ being generated, so without
the skbs being freed. And since the socket's buffer is small, there's
no way to reach that amount of packets, and the ping ends up with
"send: no buffer available" after sending 6 packets. Running with 3
instances of ping in parallel is enough to hide the problem, because
with 6 packets per instance, that's 18 packets total, which is enough
to grant a Tx interrupt before all are sent.

The original driver in the LSP kernel worked around this design flaw
by using a software timer to clean up the Tx descriptors. This timer
was slow and caused terrible network performance on some Tx-bound
workloads (such as routing) but was enough to make tools like ping
work correctly.

Instead here, we simply set the packet counts before interrupt to 1.
This ensures that each packet sent will produce an interrupt. NAPI
takes care of coalescing interrupts since the interrupt is disabled
once generated.

No measurable performance impact nor CPU usage were observed on small
nor large packets, including when saturating the link on Tx, and this
fixes tools like ping which rely on too small a send buffer. If one
wants to increase this value for certain workloads where it is safe
to do so, "ethtool -C $dev tx-frames" will override this default
setting.

This fix needs to be applied to stable kernels starting with 3.10.

Tested-By: Maggie Mae Roxas <maggie.mae.roxas@gmail.com>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
net/mlx4_core: Limit count field to 24 bits in qp_alloc_res 2014-12-16T17:09:42+00:00 Jack Morgenstein jackm@dev.mellanox.co.il 2014-11-25T09:54:31+00:00 cfcff6abc8bc6c4b9aa9e9cc93c2924a5c96b22d [ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ] Some VF drivers use the upper byte of "param1" (the qp count field) in mlx4_qp_reserve_range() to pass flags which are used to optimize the range allocation. Under the current code, if any of these flags are set, the 32-bit count field yields a count greater than 2^24, which is out of range, and this VF fails. As these flags represent a "best-effort" allocation hint anyway, they may safely be ignored. Therefore, the PF driver may simply mask out the bits. Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests" Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit 2d5c57d7fbfaa642fb7f0673df24f32b83d9066c ]

Some VF drivers use the upper byte of "param1" (the qp count field)
in mlx4_qp_reserve_range() to pass flags which are used to optimize
the range allocation.

Under the current code, if any of these flags are set, the 32-bit
count field yields a count greater than 2^24, which is out of range,
and this VF fails.

As these flags represent a "best-effort" allocation hint anyway, they may
safely be ignored. Therefore, the PF driver may simply mask out the bits.

Fixes: c82e9aa0a8 "mlx4_core: resource tracking for HCA resources used by guests"
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
tg3: fix ring init when there are more TX than RX channels 2014-12-16T17:09:42+00:00 Thadeu Lima de Souza Cascardo cascardo@linux.vnet.ibm.com 2014-11-25T16:21:11+00:00 a72e06f5ed0af18baecee57adf2659583de8cdbf [ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ] If TX channels are set to 4 and RX channels are set to less than 4, using ethtool -L, the driver will try to initialize more RX channels than it has allocated, causing an oops. This fix only initializes the RX ring if it has been allocated. Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit a620a6bc1c94c22d6c312892be1e0ae171523125 ]

If TX channels are set to 4 and RX channels are set to less than 4,
using ethtool -L, the driver will try to initialize more RX channels
than it has allocated, causing an oops.

This fix only initializes the RX ring if it has been allocated.

Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
xen-netfront: Remove BUGs on paged skb data which crosses a page boundary 2014-12-16T17:09:42+00:00 Seth Forshee seth.forshee@canonical.com 2014-11-26T02:28:24+00:00 0a8c00c7edd66707bc60fb0dee21bdb2740baf4e commit 8d609725d4357f499e2103e46011308b32f53513 upstream. These BUGs can be erroneously triggered by frags which refer to tail pages within a compound page. The data in these pages may overrun the hardware page while still being contained within the compound page, but since compound_order() evaluates to 0 for tail pages the assertion fails. The code already iterates through subsequent pages correctly in this scenario, so the BUGs are unnecessary and can be removed. Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit") Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Reviewed-by: David Vrabel <david.vrabel@citrix.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 8d609725d4357f499e2103e46011308b32f53513 upstream.

These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Signed-off-by: Seth Forshee <seth.forshee@canonical.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rt2x00: do not align payload on modern H/W 2014-12-06T23:05:49+00:00 Stanislaw Gruszka sgruszka@redhat.com 2014-11-11T13:28:47+00:00 158a695a37743947958ca415fcea2dbd88ee7661 commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream. RT2800 and newer hardware require padding between header and payload if header length is not multiple of 4. For historical reasons we also align payload to to 4 bytes boundary, but such alignment is not needed on modern H/W. Patch fixes skb_under_panic problems reported from time to time: https://bugzilla.kernel.org/show_bug.cgi?id=84911 https://bugzilla.kernel.org/show_bug.cgi?id=72471 http://marc.info/?l=linux-wireless&m=139108549530402&w=2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591 Panic happened because we eat 4 bytes of skb headroom on each (re)transmission when sending frame without the payload and the header length not being multiple of 4 (i.e. QoS header has 26 bytes). On such case because paylad_aling=2 is bigger than header_align=0 we increase header_align by 4 bytes. To prevent that we could change the check to: if (payload_length && payload_align > header_align) header_align += 4; but not aligning payload at all is more effective and alignment is not really needed by H/W (that has been tested on OpenWrt project for few years now). Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi> Debugged-by: Antti S. Lankila <alankila@bel.fi> Reported-by: Henrik Asp <solenskiner@gmail.com> Originally-From: Helmut Schaa <helmut.schaa@googlemail.com> Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream.

RT2800 and newer hardware require padding between header and payload if
header length is not multiple of 4.

For historical reasons we also align payload to to 4 bytes boundary, but
such alignment is not needed on modern H/W.

Patch fixes skb_under_panic problems reported from time to time:

https://bugzilla.kernel.org/show_bug.cgi?id=84911
https://bugzilla.kernel.org/show_bug.cgi?id=72471
http://marc.info/?l=linux-wireless&m=139108549530402&w=2
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591

Panic happened because we eat 4 bytes of skb headroom on each
(re)transmission when sending frame without the payload and the header
length not being multiple of 4 (i.e. QoS header has 26 bytes). On such
case because paylad_aling=2 is bigger than header_align=0 we increase
header_align by 4 bytes. To prevent that we could change the check to:

	if (payload_length && payload_align > header_align)
		header_align += 4;

but not aligning payload at all is more effective and alignment is not
really needed by H/W (that has been tested on OpenWrt project for few
years now).

Reported-and-tested-by: Antti S. Lankila <alankila@bel.fi>
Debugged-by: Antti S. Lankila <alankila@bel.fi>
Reported-by: Henrik Asp <solenskiner@gmail.com>
Originally-From: Helmut Schaa <helmut.schaa@googlemail.com>
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: dev: avoid calling kfree_skb() from interrupt context 2014-12-06T23:05:49+00:00 Thomas Körper thomas.koerper@esd.eu 2014-10-31T06:33:54+00:00 6e5837921cf4416edadae6ff6add38917175ac8e commit 5247a589c24022ab34e780039cc8000c48f2035e upstream. ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX Error) interrupt, which triggers the folloing warning: [ 1153.360705] ------------[ cut here ]------------ [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0() [ 1153.360772] Call Trace: [ 1153.360778] [<c167906f>] dump_stack+0x41/0x52 [ 1153.360782] [<c105bb7e>] warn_slowpath_common+0x7e/0xa0 [ 1153.360784] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360786] [<c158b909>] ? skb_release_head_state+0xb9/0xd0 [ 1153.360788] [<c105bc42>] warn_slowpath_null+0x22/0x30 [ 1153.360791] [<c158b909>] skb_release_head_state+0xb9/0xd0 [ 1153.360793] [<c158be90>] skb_release_all+0x10/0x30 [ 1153.360795] [<c158bf06>] kfree_skb+0x36/0x80 [ 1153.360799] [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360802] [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360805] [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402] [ 1153.360809] [<c10a75b5>] handle_irq_event_percpu+0x35/0x180 [ 1153.360811] [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180 [ 1153.360813] [<c10a7731>] handle_irq_event+0x31/0x50 [ 1153.360816] [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120 [ 1153.360818] [<c10a9c10>] ? handle_edge_irq+0x110/0x110 [ 1153.360822] [<c1011b61>] handle_irq+0x71/0x90 [ 1153.360823] <IRQ> [<c168152c>] do_IRQ+0x3c/0xd0 [ 1153.360829] [<c1680b6c>] common_interrupt+0x2c/0x34 [ 1153.360834] [<c107d277>] ? finish_task_switch+0x47/0xf0 [ 1153.360836] [<c167c27b>] __schedule+0x35b/0x7e0 [ 1153.360839] [<c10a5334>] ? console_unlock+0x2c4/0x4d0 [ 1153.360842] [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890 [ 1153.360845] [<c10707b6>] ? process_one_work+0x196/0x370 [ 1153.360847] [<c167c723>] schedule+0x23/0x60 [ 1153.360849] [<c1070de1>] worker_thread+0x161/0x460 [ 1153.360852] [<c1090fcf>] ? __wake_up_locked+0x1f/0x30 [ 1153.360854] [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0 [ 1153.360856] [<c1074f01>] kthread+0xa1/0xc0 [ 1153.360859] [<c1680401>] ret_from_kernel_thread+0x21/0x30 [ 1153.360861] [<c1074e60>] ? kthread_create_on_node+0x110/0x110 [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]--- This patch replaces the kfree_skb() by dev_kfree_skb_any(). Signed-off-by: Thomas Körper <thomas.koerper@esd.eu> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 5247a589c24022ab34e780039cc8000c48f2035e upstream.

ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX
Error) interrupt, which triggers the folloing warning:

[ 1153.360705] ------------[ cut here ]------------
[ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0()
[ 1153.360772] Call Trace:
[ 1153.360778]  [<c167906f>] dump_stack+0x41/0x52
[ 1153.360782]  [<c105bb7e>] warn_slowpath_common+0x7e/0xa0
[ 1153.360784]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360786]  [<c158b909>] ? skb_release_head_state+0xb9/0xd0
[ 1153.360788]  [<c105bc42>] warn_slowpath_null+0x22/0x30
[ 1153.360791]  [<c158b909>] skb_release_head_state+0xb9/0xd0
[ 1153.360793]  [<c158be90>] skb_release_all+0x10/0x30
[ 1153.360795]  [<c158bf06>] kfree_skb+0x36/0x80
[ 1153.360799]  [<f8486938>] ? can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360802]  [<f8486938>] can_free_echo_skb+0x28/0x40 [can_dev]
[ 1153.360805]  [<f849a12c>] esd_pci402_interrupt+0x34c/0x57a [esd402]
[ 1153.360809]  [<c10a75b5>] handle_irq_event_percpu+0x35/0x180
[ 1153.360811]  [<c10a7623>] ? handle_irq_event_percpu+0xa3/0x180
[ 1153.360813]  [<c10a7731>] handle_irq_event+0x31/0x50
[ 1153.360816]  [<c10a9c7f>] handle_fasteoi_irq+0x6f/0x120
[ 1153.360818]  [<c10a9c10>] ? handle_edge_irq+0x110/0x110
[ 1153.360822]  [<c1011b61>] handle_irq+0x71/0x90
[ 1153.360823]  <IRQ>  [<c168152c>] do_IRQ+0x3c/0xd0
[ 1153.360829]  [<c1680b6c>] common_interrupt+0x2c/0x34
[ 1153.360834]  [<c107d277>] ? finish_task_switch+0x47/0xf0
[ 1153.360836]  [<c167c27b>] __schedule+0x35b/0x7e0
[ 1153.360839]  [<c10a5334>] ? console_unlock+0x2c4/0x4d0
[ 1153.360842]  [<c13df500>] ? n_tty_receive_buf_common+0x890/0x890
[ 1153.360845]  [<c10707b6>] ? process_one_work+0x196/0x370
[ 1153.360847]  [<c167c723>] schedule+0x23/0x60
[ 1153.360849]  [<c1070de1>] worker_thread+0x161/0x460
[ 1153.360852]  [<c1090fcf>] ? __wake_up_locked+0x1f/0x30
[ 1153.360854]  [<c1070c80>] ? rescuer_thread+0x2f0/0x2f0
[ 1153.360856]  [<c1074f01>] kthread+0xa1/0xc0
[ 1153.360859]  [<c1680401>] ret_from_kernel_thread+0x21/0x30
[ 1153.360861]  [<c1074e60>] ? kthread_create_on_node+0x110/0x110
[ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]---

This patch replaces the kfree_skb() by dev_kfree_skb_any().

Signed-off-by: Thomas Körper <thomas.koerper@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
can: esd_usb2: fix memory leak on disconnect 2014-12-06T23:05:48+00:00 Alexey Khoroshilov khoroshilov@ispras.ru 2014-10-10T20:31:07+00:00 b248afd9f29ad863bbafa7ae71a488e547720b20 commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream. It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds the missing deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru> Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream.

It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds
the missing deallocation.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Acked-by: Matthias Fuchs <matthias.fuchs@esd.eu>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
pptp: fix stack info leak in pptp_getname() 2014-12-06T23:05:47+00:00 Mathias Krause minipli@googlemail.com 2014-11-19T17:05:26+00:00 f0eed5a220e777b9e01b9eb45d7e387a35f1f6fa [ Upstream commit a5f6fc28d6e6cc379c6839f21820e62262419584 ] pptp_getname() only partially initializes the stack variable sa, particularly only fills the pptp part of the sa_addr union. The code thereby discloses 16 bytes of kernel stack memory via getsockname(). Fix this by memset(0)'ing the union before. Cc: Dmitry Kozlov <xeb@mail.ru> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit a5f6fc28d6e6cc379c6839f21820e62262419584 ]

pptp_getname() only partially initializes the stack variable sa,
particularly only fills the pptp part of the sa_addr union. The code
thereby discloses 16 bytes of kernel stack memory via getsockname().

Fix this by memset(0)'ing the union before.

Cc: Dmitry Kozlov <xeb@mail.ru>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
qmi_wwan: Add support for HP lt4112 LTE/HSPA+ Gobi 4G Modem 2014-12-06T23:05:47+00:00 Martin Hauke mardnh@gmx.de 2014-11-16T18:55:25+00:00 3b0c6ddf7b237a203de34024de655cbb30e928b2 [ Upstream commit bb2bdeb83fb125c95e47fc7eca2a3e8f868e2a74 ] Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e) Signed-off-by: Martin Hauke <mardnh@gmx.de> Acked-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
[ Upstream commit bb2bdeb83fb125c95e47fc7eca2a3e8f868e2a74 ]

Added the USB VID/PID for the HP lt4112 LTE/HSPA+ Gobi 4G Modem (Huawei me906e)

Signed-off-by: Martin Hauke <mardnh@gmx.de>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>