Bug#670241: marked as done (linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy kernels)
Your message dated Tue, 17 Jul 2012 20:44:46 +0100
with message-id <20120717194446.GX1894@decadent.org.uk>
and subject line Re: Bug#670241: Updated qmi_wwan backport based on v3.2.19, including new device IDs from v3.5-rc1
has caused the Debian Bug report #670241,
regarding linux-2.6: Backporting the qmi_wwan driver to the Debian 3.2/wheezy kernels
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact email@example.com
Debian Bug Tracking System
Contact firstname.lastname@example.org with problems
--- Begin Message ---
-----BEGIN PGP SIGNED MESSAGE-----
Please add the qmi_wwan driver from current (v3.4-rc)
mainline to the Debian linux-3.2 based kernels. This
is as simple as cherry-picking the commits listed below in
the listed order. I've verified that the list applies
cleanly on top of v3.2.16 and that it produces the expected
CONFIG_USB_NET_QMI_WWAN must of course be enabled after
adding the driver. No other CONFIG changes are necessary.
The first batch updates the existing cdc-wdm driver to the
version in v3.4-rc4, except for the module_usb_driver()
changes from commit 65db43054. That commit touches a large
number of unrelated drivers, and all listed commits apply
cleanly without it, so I believe it's best ignored. The
other changes are necessary to add the subdriver interface
used by the qmi_wwan driver.
The second batch is just a single bugfix for the sierra
driver, which is necessary to allow the qmi_wwan driver
to support some Sierra Wireless devices. This could have
gone to stable/linux-3.2.y but I did't submit it there as
it is mostly irrelevant without the qmi_wwan driver.
The third batch adds the new qmi_wwan driver as it will appear
in v3.4-rc5. The driver has been stabilizing for a while,
and I don't expect any major changes to it in the near future.
Thanks for considering this. Let me know if there are any
problems with this request.
1) add subdriver support to cdc-wdm
19b85b3 USB: cdc-wdm: no need to fill the in request URB every time it's submitted
8143a89 USB: cdc-wdm: kill the now unnecessary bMaxPacketSize0 field and udev variable
820c629 USB: cdc-wdm: avoid printing odd-looking "cdc-wdm-176" names
fec67b4 usb: cdc-wdm: Add device-id for Huawei 3G/LTE modems
8804420 usb: cdc-wdm: make reset work with blocking IO
8457d99 USB: cdc-wdm: no need to use usb_alloc_coherent
0dffb48 usb: cdc-wdm: split out reusable parts of probe
b0c1386 usb: cdc-wdm: adding list lookup indirection
3cc3615 usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support
2) prevent sierra from binding to QMI/wwan interfaces
749541d USB: sierra: avoid QMI/wwan interface on MC77xx
3) add qmi_wwan driver
423ce8c net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
c3ecb08 net: qmi_wwan: support devices having a shared QMI/wwan interface
b086cf0 net: qmi_wwan: add Gobi and Pantech UML290 device IDs
11207b6 net: qmi_wwan: add support for ZTE MF820D
1aa35a2 USB: qmi_wwan: Add ZTE (Vodafone) K3565-Z and K4505-Z net interfaces
dbb6d09 USB: qmi_wwan: Add ZTE (Vodafone) K3570-Z and K3571-Z net interfaces
3bc17d1 net: qmi_wwan: support Sierra Wireless MC77xx devices in QMI mode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
-----END PGP SIGNATURE-----
--- End Message ---
--- Begin Message ---
On Tue, Jul 17, 2012 at 09:13:59PM +0200, Bjørn Mork wrote:
> Ben Hutchings <email@example.com> writes:
> > New hardware
> > support is a perfectly good reason for a freeze exception, whichever
> > package it's in.
> Sure, and I appreciate that. But do note that this driver does not add
> support for any new USB device. All supported modems are composite
> devices having at least one serial port supporting PPP. This means that
> the driver isn't critical for basic device support. It only adds
> support for another device function, which most users will see as
OK, then I'm closing this as not needed.
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
--- End Message ---