[PATCH net] net: qmi_wwan: fix Gobi device probing

[PATCH net] net: qmi_wwan: fix Gobi device probing

[Bjørn Mork]

Ignoring interfaces with additional descriptors is not a reliable
method for locating the correct interface on Gobi devices.  There
is at least one device where this method fails:
https://bbs.archlinux.org/viewtopic.php?id=143506

The result is that the AT command port (interface #2) is hidden
from qcserial, preventing traditional serial modem usage:

[   15.562552] qmi_wwan 4-1.6:1.0: cdc-wdm0: USB WDM device
[   15.562691] qmi_wwan 4-1.6:1.0: wwan0: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[   15.563383] qmi_wwan: probe of 4-1.6:1.1 failed with error -22
[   15.564189] qmi_wwan 4-1.6:1.2: cdc-wdm1: USB WDM device
[   15.564302] qmi_wwan 4-1.6:1.2: wwan1: register 'qmi_wwan' at usb-0000:00:1d.0-1.6, Qualcomm Gobi wwan/QMI device, 1e:df:3c:3a:4e:3b
[   15.564328] qmi_wwan: probe of 4-1.6:1.3 failed with error -22
[   15.569376] qcserial 4-1.6:1.1: Qualcomm USB modem converter detected
[   15.569440] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB0
[   15.570372] qcserial 4-1.6:1.3: Qualcomm USB modem converter detected
[   15.570430] usb 4-1.6: Qualcomm USB modem converter now attached to ttyUSB1

Use static interface numbers taken from the interface map in
qcserial for all Gobi devices instead:

	Gobi 1K USB layout:
	0: serial port (doesn't respond)
	1: serial port (doesn't respond)
	2: AT-capable modem port
	3: QMI/net

	Gobi 2K+ USB layout:
	0: QMI/net
	1: DM/DIAG (use libqcdm from ModemManager for communication)
	2: AT-capable modem port
	3: NMEA

This should be more reliable over all, and will also prevent the
noisy "probe failed" messages.  The whitelisting logic is expected
to be replaced by direct interface number matching in 3.6.

Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
 drivers/net/usb/qmi_wwan.c |   83 +++++++++++++++++++++-----------------------
 1 file changed, 40 insertions(+), 43 deletions(-)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 3b20678..3767a12 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -257,29 +257,6 @@ err:
 	return rv;
 }
 
-/* Gobi devices uses identical class/protocol codes for all interfaces regardless
- * of function. Some of these are CDC ACM like and have the exact same endpoints
- * we are looking for. This leaves two possible strategies for identifying the
- * correct interface:
- *   a) hardcoding interface number, or
- *   b) use the fact that the wwan interface is the only one lacking additional
- *      (CDC functional) descriptors
- *
- * Let's see if we can get away with the generic b) solution.
- */
-static int qmi_wwan_bind_gobi(struct usbnet *dev, struct usb_interface *intf)
-{
-	int rv = -EINVAL;
-
-	/* ignore any interface with additional descriptors */
-	if (intf->cur_altsetting->extralen)
-		goto err;
-
-	rv = qmi_wwan_bind_shared(dev, intf);
-err:
-	return rv;
-}
-
 static void qmi_wwan_unbind_shared(struct usbnet *dev, struct usb_interface *intf)
 {
 	struct usb_driver *subdriver = (void *)dev->data[0];
@@ -347,15 +324,15 @@ static const struct driver_info	qmi_wwan_shared = {
 	.manage_power	= qmi_wwan_manage_power,
 };
 
-static const struct driver_info	qmi_wwan_gobi = {
-	.description	= "Qualcomm Gobi wwan/QMI device",
+static const struct driver_info	qmi_wwan_force_int0 = {
+	.description	= "Qualcomm WWAN/QMI device",
 	.flags		= FLAG_WWAN,
-	.bind		= qmi_wwan_bind_gobi,
+	.bind		= qmi_wwan_bind_shared,
 	.unbind		= qmi_wwan_unbind_shared,
 	.manage_power	= qmi_wwan_manage_power,
+	.data		= BIT(0), /* interface whitelist bitmap */
 };
 
-/* ZTE suck at making USB descriptors */
 static const struct driver_info	qmi_wwan_force_int1 = {
 	.description	= "Qualcomm WWAN/QMI device",
 	.flags		= FLAG_WWAN,
@@ -365,6 +342,15 @@ static const struct driver_info	qmi_wwan_force_int1 = {
 	.data		= BIT(1), /* interface whitelist bitmap */
 };
 
+static const struct driver_info	qmi_wwan_force_int3 = {
+	.description	= "Qualcomm WWAN/QMI device",
+	.flags		= FLAG_WWAN,
+	.bind		= qmi_wwan_bind_shared,
+	.unbind		= qmi_wwan_unbind_shared,
+	.manage_power	= qmi_wwan_manage_power,
+	.data		= BIT(3), /* interface whitelist bitmap */
+};
+
 static const struct driver_info	qmi_wwan_force_int4 = {
 	.description	= "Qualcomm WWAN/QMI device",
 	.flags		= FLAG_WWAN,
@@ -390,16 +376,23 @@ static const struct driver_info	qmi_wwan_force_int4 = {
 static const struct driver_info	qmi_wwan_sierra = {
 	.description	= "Sierra Wireless wwan/QMI device",
 	.flags		= FLAG_WWAN,
-	.bind		= qmi_wwan_bind_gobi,
+	.bind		= qmi_wwan_bind_shared,
 	.unbind		= qmi_wwan_unbind_shared,
 	.manage_power	= qmi_wwan_manage_power,
 	.data		= BIT(8) | BIT(19), /* interface whitelist bitmap */
 };
 
 #define HUAWEI_VENDOR_ID	0x12D1
+
+/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
+#define QMI_GOBI1K_DEVICE(vend, prod) \
+	USB_DEVICE(vend, prod), \
+	.driver_info = (unsigned long)&qmi_wwan_force_int3
+
+/* Gobi 2000 and Gobi 3000 QMI/wwan interface number is 0 according to qcserial */
 #define QMI_GOBI_DEVICE(vend, prod) \
 	USB_DEVICE(vend, prod), \
-	.driver_info = (unsigned long)&qmi_wwan_gobi
+	.driver_info = (unsigned long)&qmi_wwan_force_int0
 
 static const struct usb_device_id products[] = {
 	{	/* Huawei E392, E398 and possibly others sharing both device id and more... */
@@ -510,20 +503,24 @@ static const struct usb_device_id products[] = {
 		.bInterfaceProtocol = 0xff,
 		.driver_info        = (unsigned long)&qmi_wwan_sierra,
 	},
-	{QMI_GOBI_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
-	{QMI_GOBI_DEVICE(0x03f0, 0x1f1d)},	/* HP un2400 Gobi Modem Device */
-	{QMI_GOBI_DEVICE(0x03f0, 0x371d)},	/* HP un2430 Mobile Broadband Module */
-	{QMI_GOBI_DEVICE(0x04da, 0x250d)},	/* Panasonic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x413c, 0x8172)},	/* Dell Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x1410, 0xa001)},	/* Novatel Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x0b05, 0x1776)},	/* Asus Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x19d2, 0xfff3)},	/* ONDA Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9001)},	/* Generic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9002)},	/* Generic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9202)},	/* Generic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9203)},	/* Generic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9222)},	/* Generic Gobi Modem device */
-	{QMI_GOBI_DEVICE(0x05c6, 0x9009)},	/* Generic Gobi Modem device */
+
+	/* Gobi 1000 devices */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)},	/* Acer Gobi Modem Device */
+	{QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)},	/* HP un2400 Gobi Modem Device */
+	{QMI_GOBI1K_DEVICE(0x03f0, 0x371d)},	/* HP un2430 Mobile Broadband Module */
+	{QMI_GOBI1K_DEVICE(0x04da, 0x250d)},	/* Panasonic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x413c, 0x8172)},	/* Dell Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x1410, 0xa001)},	/* Novatel Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x0b05, 0x1776)},	/* Asus Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x19d2, 0xfff3)},	/* ONDA Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9001)},	/* Generic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9002)},	/* Generic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9202)},	/* Generic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9203)},	/* Generic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9222)},	/* Generic Gobi Modem device */
+	{QMI_GOBI1K_DEVICE(0x05c6, 0x9009)},	/* Generic Gobi Modem device */
+
+	/* Gobi 2000 and 3000 devices */
 	{QMI_GOBI_DEVICE(0x413c, 0x8186)},	/* Dell Gobi 2000 Modem device (N0218, VU936) */
 	{QMI_GOBI_DEVICE(0x05c6, 0x920b)},	/* Generic Gobi 2000 Modem device */
 	{QMI_GOBI_DEVICE(0x05c6, 0x9225)},	/* Sony Gobi 2000 Modem device (N0279, VU730) */
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[David Miller]

From: Bjørn Mork <bjorn@mork.no>
Date: Thu, 21 Jun 2012 14:45:58 +0200

> Ignoring interfaces with additional descriptors is not a reliable
> method for locating the correct interface on Gobi devices.  There
> is at least one device where this method fails:
> https://bbs.archlinux.org/viewtopic.php?id=143506
> 
> The result is that the AT command port (interface #2) is hidden
> from qcserial, preventing traditional serial modem usage:
 ...
> Use static interface numbers taken from the interface map in
> qcserial for all Gobi devices instead:
 ...
> This should be more reliable over all, and will also prevent the
> noisy "probe failed" messages.  The whitelisting logic is expected
> to be replaced by direct interface number matching in 3.6.
> 
> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns@t-online.de>
> Cc: <stable@vger.kernel.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
> Cc: <stable@vger.kernel.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
> Cc: <stable@vger.kernel.org> # v3.4
> Signed-off-by: Bjørn Mork <bjorn@mork.no>

Applied.

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[Bjørn Mork]

David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:

> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Thu, 21 Jun 2012 14:45:58 +0200
>
>> Ignoring interfaces with additional descriptors is not a reliable
>> method for locating the correct interface on Gobi devices.  There
>> is at least one device where this method fails:
>> https://bbs.archlinux.org/viewtopic.php?id=143506
>> 
>> The result is that the AT command port (interface #2) is hidden
>> from qcserial, preventing traditional serial modem usage:
>  ...
>> Use static interface numbers taken from the interface map in
>> qcserial for all Gobi devices instead:
>  ...
>> This should be more reliable over all, and will also prevent the
>> noisy "probe failed" messages.  The whitelisting logic is expected
>> to be replaced by direct interface number matching in 3.6.
>> 
>> Reported-by: Heinrich Siebmanns (Harvey) <H.Siebmanns-zqRNUXuvxA0b1SvskN2V4Q@public.gmane.org>
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: 0000188 USB: qmi_wwan: Make forced int 4 whitelist generic
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4: f7142e6 USB: qmi_wwan: Add ZTE (Vodafone) K3520-Z
>> Cc: <stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org> # v3.4
>> Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
>
> Applied.

Thanks.

Note that this patch will conflict with the qmi_wwan changes already in
net-next.  I can prepare a minimal forward port if you like.

But I would really prefer to rewrite it completely for 3.6 instead,
taking advantage of the USB interface number matching in usb-next.  That
will allow us to get rid of the ugly whitelisting logic and just match
directly on the USB interface number instead.  Would that be OK?  It
will depend on 

 81df2d5 USB: allow match on bInterfaceNumber
 fec1868 USB: properly pad out usb_device_id.driver_info

from usb-next, so those must go into net-next before this is possible.
Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
an option?

I can of course also do the basic forward port now and then fix it up
later during the 3.6 cycle if you prefer that.



Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[David Miller]

From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 11:26:54 +0200

> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
> an option?

I'm extremely reluctant to have a dependency on another tree.

The USB tree, on the other hand, could pull the net-next tree
in so you can continue your dependent work there.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[Bjørn Mork]

David Miller <davem@davemloft.net> writes:

> From: Bjørn Mork <bjorn@mork.no>
> Date: Sat, 23 Jun 2012 11:26:54 +0200
>
>> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
>> an option?
>
> I'm extremely reluctant to have a dependency on another tree.

fair enough

> The USB tree, on the other hand, could pull the net-next tree
> in so you can continue your dependent work there.

OK, that will be up to Greg then.

But failing that, would it be OK to let the 3.6 version of the fix wait
for -rc2?  It's not a crash or any other kind of data loss bug, just a
usability regression with a workaround.


Bjørn

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[David Miller]

From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
Date: Sat, 23 Jun 2012 12:05:46 +0200

> But failing that, would it be OK to let the 3.6 version of the fix wait
> for -rc2?  It's not a crash or any other kind of data loss bug, just a
> usability regression with a workaround.

I'm shortly going to merge net into net-next as I periodically do,
so I'm going to have to resolve the conflict regardless of how you
finally want to fix this Gobi device probing problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH net] net: qmi_wwan: fix Gobi device probing

[Bjørn Mork]

David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:

> From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> Date: Sat, 23 Jun 2012 12:05:46 +0200
>
>> But failing that, would it be OK to let the 3.6 version of the fix wait
>> for -rc2?  It's not a crash or any other kind of data loss bug, just a
>> usability regression with a workaround.
>
> I'm shortly going to merge net into net-next as I periodically do,
> so I'm going to have to resolve the conflict regardless of how you
> finally want to fix this Gobi device probing problem.

OK.  I just sent a forward ported version for net-next.  Feel free to
use it instead of the conflicting one, or drop it if not necessary.


Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Using interface number probing for usbnet drivers before 3.6-rc1? (was: Re: [PATCH net] net: qmi_wwan: fix Gobi device probing)

[Bjørn Mork]

David Miller <davem@davemloft.net> writes:
> From: Bjørn Mork <bjorn@mork.no>
> Date: Sat, 23 Jun 2012 11:26:54 +0200
>
>> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
>> an option?
>
> I'm extremely reluctant to have a dependency on another tree.
>
> The USB tree, on the other hand, could pull the net-next tree
> in so you can continue your dependent work there.

Hello Greg,

I know I said I would be more careful about cross-tree dependencies, but
here I am again...

The context is: How should I proceed with interface number based probing
for usbnet drivers, in particular qmi_wwan which already has a few
patches in net-next?

I see two possible remaining options:

 1) you pull the net-next changes into usb-next so that I can do the
    work against usb-next now, or
 2) I wait for 3.6-rc1 and do the work against the net tree after
    3.6-rc1 is merged there

I have decided to go for option #2 unless either of you have other
preferences, as I believe that is going to cause the least work and
merge trouble for you both.

The changes are mostly device IDs, but I am also going to rip out all
the whitelist probing logic becoming redundant. This is a single driver
and pretty obvious low risk though, so I believe it is appropriate for
an -rc2.

But please let me know if I'm on the wrong track here.


Bjørn

Re: Using interface number probing for usbnet drivers before 3.6-rc1? (was: Re: [PATCH net] net: qmi_wwan: fix Gobi device probing)

[Greg Kroah-Hartman]

On Wed, Jul 04, 2012 at 01:19:35PM +0200, Bjørn Mork wrote:
> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> > From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> > Date: Sat, 23 Jun 2012 11:26:54 +0200
> >
> >> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
> >> an option?
> >
> > I'm extremely reluctant to have a dependency on another tree.
> >
> > The USB tree, on the other hand, could pull the net-next tree
> > in so you can continue your dependent work there.
> 
> Hello Greg,
> 
> I know I said I would be more careful about cross-tree dependencies, but
> here I am again...
> 
> The context is: How should I proceed with interface number based probing
> for usbnet drivers, in particular qmi_wwan which already has a few
> patches in net-next?
> 
> I see two possible remaining options:
> 
>  1) you pull the net-next changes into usb-next so that I can do the
>     work against usb-next now, or
>  2) I wait for 3.6-rc1 and do the work against the net tree after
>     3.6-rc1 is merged there
> 
> I have decided to go for option #2 unless either of you have other
> preferences, as I believe that is going to cause the least work and
> merge trouble for you both.

What about:
   3) You send the usb interface number matching patches again for them
   to be included in the net-next tree as well, causing duplicates to be
   in linux-next, but allowing you to send your patches into net-next.

That is what we have done at times for other patches, and if David is ok
with it, so am I.  Odds are, the merge will happen automatically, but if
not, I can handle it when 3.6-rc1 comes around.

Sound good?

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using interface number probing for usbnet drivers before 3.6-rc1?

[Bjørn Mork]

Greg Kroah-Hartman <gregkh@linuxfoundation.org> writes:
> On Wed, Jul 04, 2012 at 01:19:35PM +0200, Bjørn Mork wrote:
>> David Miller <davem@davemloft.net> writes:
>> > From: Bjørn Mork <bjorn@mork.no>
>> > Date: Sat, 23 Jun 2012 11:26:54 +0200
>> >
>> >> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
>> >> an option?
>> >
>> > I'm extremely reluctant to have a dependency on another tree.
>> >
>> > The USB tree, on the other hand, could pull the net-next tree
>> > in so you can continue your dependent work there.
>> 
>> Hello Greg,
>> 
>> I know I said I would be more careful about cross-tree dependencies, but
>> here I am again...
>> 
>> The context is: How should I proceed with interface number based probing
>> for usbnet drivers, in particular qmi_wwan which already has a few
>> patches in net-next?
>> 
>> I see two possible remaining options:
>> 
>>  1) you pull the net-next changes into usb-next so that I can do the
>>     work against usb-next now, or
>>  2) I wait for 3.6-rc1 and do the work against the net tree after
>>     3.6-rc1 is merged there
>> 
>> I have decided to go for option #2 unless either of you have other
>> preferences, as I believe that is going to cause the least work and
>> merge trouble for you both.
>
> What about:
>    3) You send the usb interface number matching patches again for them
>    to be included in the net-next tree as well, causing duplicates to be
>    in linux-next, but allowing you to send your patches into net-next.
>
> That is what we have done at times for other patches, and if David is ok
> with it, so am I.  Odds are, the merge will happen automatically, but if
> not, I can handle it when 3.6-rc1 comes around.
>
> Sound good?

I could have misunderstood, but I thought that was out of the question
given that David didn't want to cherry-pick them from usb-next.


Bjørn 

Re: Using interface number probing for usbnet drivers before 3.6-rc1?

[Greg Kroah-Hartman]

On Wed, Jul 04, 2012 at 04:50:53PM +0200, Bjørn Mork wrote:
> Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
> > On Wed, Jul 04, 2012 at 01:19:35PM +0200, Bjørn Mork wrote:
> >> David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> writes:
> >> > From: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
> >> > Date: Sat, 23 Jun 2012 11:26:54 +0200
> >> >
> >> >> Is waiting for 3.6-rc1 the best alternative, or is cherry-picking them
> >> >> an option?
> >> >
> >> > I'm extremely reluctant to have a dependency on another tree.
> >> >
> >> > The USB tree, on the other hand, could pull the net-next tree
> >> > in so you can continue your dependent work there.
> >> 
> >> Hello Greg,
> >> 
> >> I know I said I would be more careful about cross-tree dependencies, but
> >> here I am again...
> >> 
> >> The context is: How should I proceed with interface number based probing
> >> for usbnet drivers, in particular qmi_wwan which already has a few
> >> patches in net-next?
> >> 
> >> I see two possible remaining options:
> >> 
> >>  1) you pull the net-next changes into usb-next so that I can do the
> >>     work against usb-next now, or
> >>  2) I wait for 3.6-rc1 and do the work against the net tree after
> >>     3.6-rc1 is merged there
> >> 
> >> I have decided to go for option #2 unless either of you have other
> >> preferences, as I believe that is going to cause the least work and
> >> merge trouble for you both.
> >
> > What about:
> >    3) You send the usb interface number matching patches again for them
> >    to be included in the net-next tree as well, causing duplicates to be
> >    in linux-next, but allowing you to send your patches into net-next.
> >
> > That is what we have done at times for other patches, and if David is ok
> > with it, so am I.  Odds are, the merge will happen automatically, but if
> > not, I can handle it when 3.6-rc1 comes around.
> >
> > Sound good?
> 
> I could have misunderstood, but I thought that was out of the question
> given that David didn't want to cherry-pick them from usb-next.

Well, I said to email them again, which makes it easier for David, but
if he doesn't want to do that, then you will have to wait for option 2
above, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html