[PATCH 1/1] support new huawei devices in option.c
1. Add new supporting declarations to option.c, to support Huawei new devices
with new bInterfaceProtocol value.
Signed-off-by: fangxiaozhi huana...@huawei.com
--- linux-3.12.1/drivers/usb/serial/option.bk 2013-11-29 14:49:44.528970754
+0800
+++ linux-3.12.1/drivers/usb/serial/option.c2013-11-29 15:22:01.0
+0800
@@ -634,6 +634,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x7A) },
@@ -688,6 +692,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7A) },
@@ -742,6 +750,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x7A) },
@@ -796,6 +808,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x7A) },
@@ -850,6 +866,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x75) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x78) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x79) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x05, 0x7A) },
@@ -904,6 +924,10 @@
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6D) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6E) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x72) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x73) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x74) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x06, 0x75) },
RE: [PATCH 1/1] support new huawei devices in option.c
Dear Greg:
-Original Message-
From: gre...@linuxfoundation.org [mailto:gre...@linuxfoundation.org]
Sent: Saturday, October 12, 2013 4:58 AM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Heyongquan;
Wangyuhua; Yili (Neil)
Subject: Re: [PATCH 1/1] support new huawei devices in option.c
On Fri, Oct 11, 2013 at 03:48:21AM +, Fangxiaozhi (Franko) wrote:
1. Add new supporting declarations to option.c, to support Huawei new
devices with new bInterfaceSubClass value.
Signed-off-by: fangxiaozhi huana...@huawei.com
In the future, can you use an email client that doesn't turn tabs into spaces,
so I
don't have to edit the patch by hand?
Also:
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
0x01)
+ }, { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03,
+ 0x02) },
snip
That's a huge list of ids, is there any way we can just mark all of these as
used by
the device in an easier manner?
-OK, I will. Thank you very much.
I'll take this for now, but I have a feeling that this list is just going to
get worse
over time, right?
-Yes, I think so. So we are discussing about this internally, and maybe try
to optimize it later.
thanks,
greg k-h
Best Regards,
Franko Fang
--
To unsubscribe from this list: send the line unsubscribe linux-usb in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] support new huawei devices in option.c
1. Add new supporting declarations to option.c, to support Huawei new devices
with new bInterfaceSubClass value.
Signed-off-by: fangxiaozhi huana...@huawei.com
--- linux-3.11.4-orig/drivers/usb/serial/option.c 2013-10-10 16:13:25.443072876
+0800
+++ linux-3.11.4/drivers/usb/serial/option.c 2013-10-10 15:51:44.17799 +0800
@@ -686,6 +686,222 @@ static const struct usb_device_id option
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7A) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7B) },
{ USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x02, 0x7C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x03) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x05) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x06) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x0A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x0B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x0D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x0E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x0F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x10) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x12) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x13) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x14) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x15) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x17) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x18) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x19) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x1A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x1B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x1C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x31) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x32) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x33) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x34) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x35) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x36) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x3A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x3B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x3D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x3E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x3F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x48) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x49) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x4A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x4B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x4C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x61) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x62) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x63) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x64) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x65) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x66) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x6F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x78) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x79) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x7A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x7B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x03, 0x7C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x03) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x04, 0x05) },
+ {
RE: 答复: [PATCH] USB: storage: fix Huawei mode switching regression
Dear All：
As far as I know, except switching in kernel, there isn't any mode
switch solution on Android now.
Do you have any good ideas for the mode switch on Android system?
Best Regards,
Franko Fang
-Original Message-
From: Dan Williams [mailto:d...@redhat.com]
Sent: Wednesday, March 06, 2013 11:46 PM
To: Greg KH
Cc: Linlei (Lei Lin); Bjørn Mork; linux-usb@vger.kernel.org;
linux-ker...@vger.kernel.org; Xueguiying (Zihan); Yili (Neil); Wangyuhua;
Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc; stable; Fangxiaozhi (Franko)
Subject: Re: 答复: [PATCH] USB: storage: fix Huawei mode switching
regression
On Wed, 2013-03-06 at 09:44 +0800, Greg KH wrote:
On Wed, Mar 06, 2013 at 01:34:44AM +, Linlei (Lei Lin) wrote:
Hello Mork,
-- Because in the embedded linux system, Android, or Chrome
OS, etc. They don't integrate userspace usb_modeswitch utility
for switching.
Why not? If they can upgrade the kernel, then they most certainly can
install a userspace utility.
There is no excuse for an embedded system to do this differently.
Please see e.g. OpenWRT as an example of an embedded system doing
this correctly.
But currently Android and Chrome OS has not integrated the
usb_modeswitch utility.
That is not a kernel problem. I find it hard to believe that Chrome
OS would not gladly accept code to resolve this issue, can't you put
it into the modemmanager or whatever Chrome OS uses to handle their
wireless modems?
They use ModemManager, and that's still not the best place to put
modeswitching. The best place to modeswitch anything is usb_modeswitch.
No sense duplicating the functionality that usb_modeswitch already supplies.
Dan
As for Android, sorry, you are on your own, you will just have to deal
with the individual OEMs that are incorporating your hardware :(
From a vendor's point of view, our purpose is to make our devices be
supported natively by those OS.
We have a solution, usb_modeswitch, any user should be using that.
So we consider that add the switch function to the kernel resolves
the problem from the source.
Then this function will be inherited by Android Chrome OS.
Don't circumvent horribly governed userspace projects by getting
changes into the Linux kernel. Go fix those projects instead.
Good luck,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-usb
in the body of a message to majord...@vger.kernel.org More majordomo
info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
RE: v3.8 regression: Huawei mode switching fails (was Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command)
Dear Oliver:
-Original Message-
From: Oliver Neukum [mailto:oneu...@suse.de]
Sent: Tuesday, March 05, 2013 4:49 PM
To: Fangxiaozhi (Franko)
Cc: Bjørn Mork; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
Xueguiying (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua
(Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc
Subject: Re: v3.8 regression: Huawei mode switching fails (was Re: [PATCH
2/2]linux-usb:optimize to match the Huawei USB storage devices and support
new switch command)
On Tuesday 05 March 2013 02:28:07 Fangxiaozhi wrote:
Hi,
1. As far as I know, usb_modeswitch is now only integrated in the PC
Linux.
It isn't integrated to other system with linux kernel, such as Android, Chrome
OS, etc. On these system, how can we switch the device?
Then those systems will have to add modeswitch.
If we are to do mode switching in kernel space, there has to be an additional
technical benefit over the existing and well working solution in user space.
-The vendor doesn't want to add the modeswitch on their system. We try to
push them to do it, but they don't agree.
2. usb_modeswitch often sends the Windows switching command to
switch Huawei device, but not sends Linux switching command. This maybe
causes some unexpected problem.
You have two commands? What is the difference? Anyway, if usb_modeswitch
has issues, these problems need to be fixed.
--Sorry, it is one command, but with different values in it for different
system, such as:
1. For Windows:
{0x11, 0x06, 0x00, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
2. For Mac OS:
{0x11, 0x06, 0x10, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
3. For Linux:
{0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
- 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
Sometimes, modeswitch will send the command for Windows to device on
Linux system, but not the command for Linux.
Independent from that, there is a problem with user space mode switching.
Namely it doesn't work with reset_resume(). Thus we cannot do sane S4 with
the user space solution.
However, the problem cannot be solved by merely by adding the switch to the
storage driver.
-For this issue, can you offer more details? And we can try to solve it
together.
Regards
Oliver
Best Regards,
Franko Fang
RE: [PATCH] USB: storage: fix Huawei mode switching regression
-Original Message-
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 04, 2013 9:19 PM
To: linux-usb@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; Fangxiaozhi (Franko); Xueguiying (Zihan);
Linlei (Lei Lin); Greg KH; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc;
Bjørn Mork; stable
Subject: [PATCH] USB: storage: fix Huawei mode switching regression
This reverts commit 200e0d99 (USB: storage: optimize to match the Huawei
USB storage devices and support new switch command and the followup
bugfix commit cd060956 (USB: storage: properly handle the endian issues of
idProduct).
The commit effectively added a large number of Huawei devices to the
deprecated usb-storage mode switching logic. Many of these devices have
been in use and supported by the userspace usb_modeswitch utility for years.
Forcing the switching inside the kernel causes a number of regressions as a
result of ignoring existing onfigurations, and also completely takes away the
ability to configure mode switching per device/system/user.
-- commit 200e0d99 and commit cd060956, only put the switch command into
kernel, instead of userspace usb_modeswitch utility.
-- Because in the embedded linux system, Android, or Chrome OS, etc. They
don't integrate userspace usb_modeswitch utility for switching.
- In commit 200e0d99, we send the Linux switching command to Huawei
devices, so on PC Linux, you can get the largest capacity of Huawei device,
including the CDROM feature. So I think this solution can meet the user's
requirement in Linux.
Known regressions caused by this:
- Some of the devices support multiple modes, using different
switching commands. There are existing configurations taking
advantage of this.
---But in this multiple modes, there is only one is for Linux. We don't
advice the user to use the other mode not for Linux. It may cause some
unexpected problem.
- There is a real use case for disabling mode switching and
instead mounting the exposed storage device. This becomes
impossible with switching logic inside the usb-storage driver.
In commit 200e0d99, the switching command will ask Huawei device to offer
the CDROM(and /or SD) port together. After switching, users also can get the
mounting storage device.
- At least on device fail as a result of the usb-storage switching
command, becoming completely unswitchable. This is possibly a
firmware bug, but still a regression because the device work as
expected using usb_modeswitch defaults.
- If the kernel solution encounters this issue, then it also will occur
with usb_modeswitch.
In-kernel mode switching was deprecated years ago with the development of
the more user friendly userspace alternatives. The existing list of devices in
usb-storage was only kept to prevent breaking already working systems. The
long term plan is to remove the list, not to add to it. Ref:
http://permalink.gmane.org/gmane.linux.usb.general/28543
Cc: fangxiao...@huawei.com
Cc: stable sta...@vger.kernel.org
Signed-off-by: Bjørn Mork bj...@mork.no
---
I just realized that this already had gone into maintained stable series',
making
the fix so much more urgent. This needs to be reverted before it starts
hitting innocent distro users. So I am sending the patch now instead of
waiting for Huawei to respond.
-- In our opinions, it is better to switch Huawei device in kernel.
-- usb_modeswitch is a tool for Linux.
-- We can not guarantee it will be integrated in all the system which
integrates linux kernel. But linux kernel itself can.
Bjørn
Best Regards,
Franko Fang
drivers/usb/storage/initializers.c | 76 +
drivers/usb/storage/initializers.h |4 +-
drivers/usb/storage/unusual_devs.h | 329
+++-
3 files changed, 331 insertions(+), 78 deletions(-)
diff --git a/drivers/usb/storage/initializers.c
b/drivers/usb/storage/initializers.c
index 7ab9046..105d900 100644
--- a/drivers/usb/storage/initializers.c
+++ b/drivers/usb/storage/initializers.c
@@ -92,8 +92,8 @@ int usb_stor_ucr61s2b_init(struct us_data *us)
return 0;
}
-/* This places the HUAWEI usb dongles in multi-port mode */ -static int
usb_stor_huawei_feature_init(struct us_data *us)
+/* This places the HUAWEI E220 devices in multi-port mode */ int
+usb_stor_huawei_e220_init(struct us_data *us)
{
int result;
@@ -104,75 +104,3 @@ static int usb_stor_huawei_feature_init(struct
us_data *us)
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
-
-/*
- * It will send a scsi switch command called rewind' to huawei dongle.
- * When the dongle receives this command at the first time,
- * it will reboot immediately. After rebooted, it will ignore this command.
- * So it is unnecessary to read its response.
- */
-static int
RE: v3.8 regression: Huawei mode switching fails (was Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command)
Dear Mork:
Thank you very much for your test.
-Original Message-
From: Bjørn Mork [mailto:bj...@mork.no]
Sent: Monday, March 04, 2013 7:41 PM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying
(Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger,
Credit);
Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc
Subject: v3.8 regression: Huawei mode switching fails (was Re: [PATCH
2/2]linux-usb:optimize to match the Huawei USB storage devices and support
new switch command)
Hello Franko,
This patch causes a number of regressions for both the Huawei devices I have
available for testing. One of them is completely unusable in v3.8 (unable to
switch to modem mode) unless the usb-storage driver is disabled.
--Which device, can you tell me more information?
--Which model? And what's its firmware version?
I realize that some devices are historically handled by the usb-storage
driver,
but userspace modeswitching is the rule for new devices AFAIK.
I see absolutely no valid argument for adding new devices. And there is
absolutely no excuse for adding devices which have been handled by
userspace switching for years! The patch does not just optimize
matching. It adds a large number of devices which were previously handled
just fine by usb_modeswitch. This is guaranteed to confuse users with existing
configurations, and users looking up any of the existing documentation
pointing to usb_modeswitch.
--Yes. But there is some problems for this:
1. As far as I know, usb_modeswitch is now only integrated in the PC
Linux. It isn't integrated to other system with linux kernel, such as Android,
Chrome OS, etc. On these system, how can we switch the device?
2. usb_modeswitch often sends the Windows switching command to switch
Huawei device, but not sends Linux switching command. This maybe causes some
unexpected problem.
There is no need to repeat the discussion of kernel vs userspace switching. I
will only note that userspace switching:
- has been selected as the rule for new devices,
- allow the user to temporarily disable switching e.g. for mounting and
inspecting the usb-storage exported data,
- allow the user/system to apply device specific switching quirks
The v3.7-v3.8 regressions I observe are:
1) Temporarily disabling mode switching and mounting the CD image is now
impossible. Mode switching can only be disabled by blacklisting
usb-storage, which of course prevents usb-storage from working
Prior to v3.8, modeswitching could easily be disabled by userspace
configuration. The change breaks existing configurations.
2) Switching to non-default modes is now impossible. The E392 (initially
appearing as 12d1:1505) Windows drivers will use a different command than
the one used by Linux, causing the device to select a different configuration
in Linux and Windows. This forces Linux and Windows to see the device
differently.
Prior to v3.8, different modeswitching commands could be configured per
device. The change breaks existing configurations.
3) Switching fails for some devices. The E367 (initially appearing as
12d1:1446) does not switch when it receives the command sent by
usb-storage. But the command disable further switching, preventing
userspace switching from working as well.
Prior to v3.8, the device would switch fine using a default usb_modeswitch
configuration. The change breaks existing configurations.
I do note that there is a slight difference between the known working
usb_modeswitch command:
55534243123456780011062001
and the command sent by usb-storage:
char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
I assume the cause of the failure is either this difference or some timing
issue.
Anyway, I believe this patch must be reverted. It disables currently used,
well
documented, and extremely useful, userspace funtionaliy for all devices
implicitly added by the conversion from device matching to vendor matching.
Bjørn
Best Regards,
Franko Fang
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
RE: [PATCH 1/2] USB: storage: Define a new macro for USB storage match rules
Dear Greg：
OK，thank you very much.
Best Regards,
Franko Fang
-Original Message-
From: Greg KH [mailto:gre...@linuxfoundation.org]
Sent: Tuesday, February 05, 2013 2:39 AM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying
(Zihan);
Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C);
ba...@ti.com;
mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc
Subject: Re: [PATCH 1/2] USB: storage: Define a new macro for USB storage
match rules
On Mon, Feb 04, 2013 at 03:14:46PM +0800, fangxiaozhi 00110321 wrote:
+/* Define the device is matched with Vendor ID and interface
+descriptors */ #define UNUSUAL_VENDOR_INTF(id_vendor, cl, sc, pr, \
+ vendorName, productName, useProtocol, useTransport, \
+ initFunction, flags) \
+{ \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor= (id_vendor), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr), \
+ .driver_info = (flags) \
+}
I'm not going to reject this given the number of times it has been submitted,
but can't you use the USB_VENDOR_AND_INTERFACE_INFO() macro here in
this definition?
If so, can you send me an add-on patch that makes that change?
thanks,
greg k-h
RE: [PATCH 1/2]linux-usb:Define a new macro for USB storage match rules
-Original Message-
From: Greg KH [mailto:g...@kroah.com]
Sent: Saturday, January 26, 2013 1:45 AM
To: Fangxiaozhi (Franko)
Cc: Sergei Shtylyov; linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org;
Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit);
Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net;
sebast...@breakpoint.cc
Subject: Re: [PATCH 1/2]linux-usb:Define a new macro for USB storage match
rules
On Fri, Jan 25, 2013 at 04:18:34PM +0400, Sergei Shtylyov wrote:
Hello.
On 25-01-2013 6:44, fangxiaozhi 00110321 wrote:
From: fangxiaozhi huana...@huawei.com
1. Define a new macro for USB storage match rules:
matching with Vendor ID and interface descriptors.
Signed-off-by: fangxiaozhi huana...@huawei.com
diff -uprN linux-3.8-rc4_orig/drivers/usb/storage/usb.c
linux-3.8-rc4/drivers/usb/storage/usb.c
--- linux-3.8-rc4_orig/drivers/usb/storage/usb.c 2013-01-22
14:12:42.595238727 +0800
+++ linux-3.8-rc4/drivers/usb/storage/usb.c 2013-01-22
+++ 14:16:01.398250305 +0800
@@ -120,6 +120,17 @@ MODULE_PARM_DESC(quirks, supplemental l
.useTransport = use_transport, \
}
+#define UNUSUAL_VENDOR_INTF(idVendor, cl, sc, pr, \
+ vendor_name, product_name, use_protocol, use_transport, \
+ init_function, Flags) \
+{ \
+ .vendorName = vendor_name, \
+ .productName = product_name, \
+ .useProtocol = use_protocol, \
+ .useTransport = use_transport, \
+ .initFunction = init_function, \
+}
Shouldn't the field initilaizers be indented with tab, not space?
Yes it must. fangxiaozhi, please always run your patches through the
scripts/checkpatch.pl tool before sending them out (note, you will have to
ignore the CamelCase warnings your patch produces, but not the other
ones.)
-What's wrong with it?
-I have checked the patches with scripts/checkpatch.pl before sending.
-There is no other warning or error in my patches except CamelCase warnings.
-So what's wrong now?
Please do that on both of these patches and resend them.
thanks,
greg k-h
RE: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices
Dear Greg: OK, I have fixed up and resend the patches based on linux-3.8-rc4 today. Email subjects: 1. [PATCH 1/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices 2. [PATCH 2/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices Please apply them, thank you very much. Best Regards, Franko Fang -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Tuesday, January 22, 2013 1:12 AM To: Fangxiaozhi (Franko) Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc Subject: Re: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices On Mon, Jan 21, 2013 at 03:37:15AM +, Fangxiaozhi (Franko) wrote: Dear Greg: I get the following errors: drivers/usb/storage/unusual_devs.h:1530:1: error: implicit declaration of function ‘UNUSUAL_VENDOR_INTF’ [-Werror=implicit-function-declaration] drivers/usb/storage/unusual_devs.h:1534:3: warning: missing braces around initializer [-Wmissing-braces] drivers/usb/storage/unusual_devs.h:1534:3: warning: (near initialization for ‘us_unusual_dev_list[186]’) [-Wmissing-braces] drivers/usb/storage/unusual_devs.h:1534:3: error: initializer element is not constant drivers/usb/storage/unusual_devs.h:1534:3: error: (near initialization for ‘us_unusual_dev_list[186].vendorName’) drivers/usb/storage/unusual_devs.h:1537:1: warning: braces around scalar initializer [enabled by default] And it goes on and on... --The macro define, please see another patch: [PATCH 1/1]linux-usb:Define a new macro for USB storage match rules http://www.spinics.net/lists/linux-usb/msg76629.html Please resend it, I do not have this patch anymore in my queue. Remember, I asked you to resend everything that was needed, with the proper ordering. Please resend all patches, properly fixed up, that you wish to see applied. thanks, greg k-h
RE: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices
Dear Greg: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Tuesday, January 22, 2013 11:04 PM To: Fangxiaozhi (Franko) Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc Subject: Re: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices On Tue, Jan 22, 2013 at 09:16:08AM +, Fangxiaozhi (Franko) wrote: Dear Greg: OK, I have fixed up and resend the patches based on linux-3.8-rc4 today. Email subjects: 1. [PATCH 1/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices 2. [PATCH 2/2]linux-usb:define new macro and add new match rules for Huawei USB storage devices You sent me two patches, both with the same exact Subject: line. That's not ok, please be descriptive in the subject lines as to what each individual patch does, as obviously they both don't do the same thing, right? No, they do the same thing, so can I submit them in only one patch? (Last time, Sebastian thought that the one patch is too long, so he advised me to separate it into two patches). Please fix that up and resend the two patches. thanks, greg k-h Best Regards, Franko Fang
RE: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices
Dear Greg: -Original Message- From: Greg KH [mailto:gre...@linuxfoundation.org] Sent: Saturday, January 19, 2013 7:42 AM To: Fangxiaozhi (Franko) Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc Subject: Re: USB: storage: optimize the matching rules and support new switch command for Huawei USB storage devices On Mon, Jan 14, 2013 at 10:55:48AM +0800, fangxiaozhi 00110321 wrote: From: fangxiaozhi huana...@huawei.com 1. Optimize the matching rules with new macro for Huawei USB storage devices, to avoid to load USB storage driver for the modem interface with Huawei devices. 2. Add to support new switch command for new Huawei USB dongles. Signed-off-by: fangxiaozhi huana...@huawei.com Next time, please always use the scripts/checkpatch.pl tool to find any problems you might have made in your patch (you had trailing whitespace in this one, which I have fixed.) -Yes, I have checked my patch with scripts/checkpatch.pl tool before submitting. -For this trailing whitespace error, I think that it is better readable to leave whitespace in our patch code. Isn't it? Also, you might want to use git, it makes creating the patches easier, that way you don't end up with lines in the patch like this one: Binary files linux-3.8-rc3_orig/drivers/usb/storage/initializers.o and linux-3.8-rc3/drivers/usb/storage/initializers.o differ thanks, greg k-h Best Regards, Franko Fang
RE: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Greg: -Original Message- From: Greg KH [mailto:g...@kroah.com] Sent: Saturday, January 12, 2013 8:22 AM To: Fangxiaozhi (Franko) Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); Yili (Neil); Wangyuhua (Roger, Credit); Huqiao (C); ba...@ti.com; mdharm-...@one-eyed-alien.net; sebast...@breakpoint.cc Subject: Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command On Fri, Jan 11, 2013 at 05:57:44PM +0800, fangxiaozhi 00110321 wrote: From: fangxiaozhi huana...@huawei.com 1. Optimize the match rules with new macro for Huawei USB storage devices, to avoid to load USB storage driver for the modem interface with Huawei devices. 2. Add to support new switch command for new Huawei USB dongles. I don't see a 1/2 patch in this series, yet I see two different 1/1 patches. --Yes, this email includes the entire patch. --I mask the 2/2 to distinguish it from the previous email, which mask 1/1. Can you resend all of your outstanding patchs, in the correct order, with the correct numbering, so I know what order to apply them in? -This email is the whole patch, so can I resend it again? thanks, greg k-h Best Regards, Franko Fang
RE: [PATCH 1/1]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Sebastian:
-Original Message-
From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc]
Sent: Thursday, January 10, 2013 5:30 AM
To: Fangxiaozhi (Franko)
Cc: Linlei (Lei Lin); Huqiao (C); linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/1]linux-usb:optimize to match the Huawei USB storage
devices and support new switch command
keep the CC list please.
On Wed, Jan 09, 2013 at 07:28:43AM +, Fangxiaozhi (Franko) wrote:
+/* This function will send
+ * a scsi switch command called rewind' to huawei dongle.
+ * When the dongle receives this command at the first time,
+ * it will reboot immediately,
+ * after rebooted, it will ignore this command and do nothing,
+ * if it receives this command again.
+ * So it is unnecessary to read its response. */
This is not how a proper multi line comment looks like. The line
break in the middle of the sentence does not look good IMHO.
---Sorry, but if not do that, the comment is longer than 80 characters
in
one line.
Don't cross 80 lines but you don't need a line break after send and
immediately, if you look at your initial patch.
+static int usb_stor_huawei_scsi_init(struct us_data *us) {
+ int result = 0;
+ int act_len = 0;
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us-iobuf;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01,
0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
+
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
-set the whole bcbw to be 0.
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Tag = 0;
+ bcbw-DataTransferLength = 0;
+ bcbw-Flags = bcbw-Lun = 0;
+ bcbw-Length = sizeof(rewind_cmd);
--initialize every elements of the struct bulk_cb_wrap.
I asked earlier and I ask again: why memset to zero followed by init to
zero.
Could we stick to one thing?
-So these codes maybe seem to be redundant, but I think it can make the
codes to more clear.
It is point less. Looking at drivers/usb/storage/transport.c at other users
and
nobody is doing it. I don't see the point in assigning a values a few times
to zero.
Please remove the = 0 assignments.
You mean that we have to write as follows?
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Length = sizeof(rewind_cmd);
Right?
+ memcpy(bcbw-CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe,
bcbw,
+ US_BULK_CB_WRAP_LEN, act_len);
This looks like it could work. Was it really tested before sending
this time? :P
-Yes, it is tested OK before our submitting.
okay then.
+ US_DEBUGP(transfer actual length=%d, result=%d\n, act_len,
result);
+ return result;
+}
+
+/* usb_stor_huawei_dongles_pid: try to find the supported Huawei
+USB dongles
+ * In Huawei, they assign the following product IDs
+ * for all of their mobile broadband dongles,
+ * including the new dongles in the future.
+ * So if the product ID is not included in this list,
+ * it means it is not Huawei's mobile broadband dongles.
+ */
Not a proper multiple line comment. Kernel doc format is different
btw. and is described in Documentation/kernel-doc-nano-HOWTO.txt
--Do you mean to write the comment like that:
Example kernel-doc function comment:
/**
* foobar() - short function description of foobar
* @arg1: Describe the first argument to foobar.
* @arg2: Describe the second argument to foobar.
* One can provide multiple line descriptions
* for arguments.
*
* A longer description, with more discussion of the function foobar()
* that might be useful to those using or modifying it. Begins with
* empty comment line, and may include additional embedded empty
* comment lines.
*
* The longer description can have multiple paragraphs.
*
* Return: Describe the return value of foobar.
*/
Yes, something like that. A short comment would work, too. However since you
added the function name in top of your comment you should stick to a
standard form.
+static int usb_stor_huawei_dongles_pid(struct us_data *us) {
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ idProduct = us-pusb_dev-descriptor.idProduct;
+ /* The first port is CDROM,
+* means the dongle in the single port mode,
+* and a switch command is required to be sent. */
+ if (idesc idesc-bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001
RE: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Matthew: -Original Message- From: Matthew Dharm [mailto:mdharm-...@one-eyed-alien.net] Sent: Wednesday, December 19, 2012 11:41 PM To: Sebastian Andrzej Siewior Cc: Fangxiaozhi (Franko); linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao; ba...@ti.com Subject: Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command On Wed, Dec 19, 2012 at 12:34 AM, Sebastian Andrzej Siewior sebast...@breakpoint.cc wrote: On Wed, Dec 19, 2012 at 03:13:32AM +, Fangxiaozhi (Franko) wrote: And shouldn't you read something from the us-recv_bulk_pipe after that? Well, because our device will re-connect to switch the ports if it receives the command. So it is not necessary to read the response of the command. Hmm. I guess this for Matthew / Greg to decide, I don't insist on anything. Maybe a comment would be nice because now it looks, atleast to me, that something is missing. I think an unusual situation like that deserves a comment that explains that the device is about to disconnect / reconnect, so reading status is not necessary. You mean that we have to add some comment in the source code, to explain why we don't read the response. Right? I am also concerned about the error of using bcbw instead of bcbw. I doubt this code would have worked with that typo in place. How was this patch tested? Also, the dongles_pid function is really just a different implementation of the unusual_devs.h table. I think that it is much easier for people to add new entries to the table, rather than edit your code, when new dongles are released. BUT, your code includes many more PIDs than the table did. Again, how was this tested for the new PIDs covered? In the dongles_pid function, we have check all the product IDs for our dongles, which is assigned for all of our Mobile Broadband products in our company. So the product ID of our new dongle in future, will also be included in this list. In our lab, we can configure our dongle firmware to support all of these product ID. We have test them(cover all the product ID), and this function works fine. At a minimum, some comment in dongles_pid is required to highlight this area of code for possible future expansion as new devices are released. As far as I know, the product ID list in dongles_pid function includes all. We will not add any other product ID for our dongle. So we need not update the product ID list in dongles_pid function in future. However, I also will add the comment to highlight the area of code, as your advice did. Matt -- Matthew Dharm Maintainer, USB Mass Storage driver for Linux Best Regards, Franko Fang
RE: [PATCH 2/2]linux-usb:optimize to match the Huawei USB storage devices and support new switch command
Dear Sebastian:
Please see the comments follows yours.
By the way, I found the kernel is updated to 3.7.1 today. So I have to
update my patch based on 3.7.1, and resubmit it?
Right?
Best Regards,
Franko Fang
-Original Message-
From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc]
Sent: Tuesday, December 18, 2012 10:10 PM
To: Fangxiaozhi (Franko)
Cc: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying
(Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger,
Credit); Huqiao; ba...@ti.com
Subject: Re: [PATCH 2/2]linux-usb:optimize to match the Huawei USB
storage devices and support new switch command
On Tue, Dec 18, 2012 at 10:44:19AM +0800, fangxiaozhi 00110321 wrote:
diff -uprN linux-3.7_bak/drivers/usb/storage/initializers.c
linux-3.7/drivers/usb/storage/initializers.c
--- linux-3.7_bak/drivers/usb/storage/initializers.c2012-12-11
09:56:11.0 +0800
+++ linux-3.7/drivers/usb/storage/initializers.c2012-12-17
11:12:12.0 +0800
US_DEBUGP(Huawei mode set result is %d\n, result);
return 0;
}
+
+/* Find the supported Huawei USB dongles */ static int
+usb_stor_huawei_dongles_pid(struct us_data *us) {
+ struct usb_interface_descriptor *idesc;
+ int idProduct;
+
+ idesc = us-pusb_intf-cur_altsetting-desc;
+ idProduct = us-pusb_dev-descriptor.idProduct;
+ if (idesc idesc-bInterfaceNumber == 0) {
+ if ((idProduct == 0x1001)
+ || (idProduct == 0x1003)
+ || (idProduct == 0x1004)
+ || (idProduct = 0x1401 idProduct 0x1501)
+ || (idProduct 0x1504 idProduct = 0x1600)
+ || (idProduct = 0x1c02 idProduct = 0x2202)) {
+ return 1;
+ }
+ }
+ return 0;
+}
+
+static int usb_stor_huawei_scsi_init(struct us_data *us) {
+ int result = 0;
+ int act_len = 0;
+ char rewind_cmd[] = {0x11, 0x06, 0x20, 0x00, 0x00, 0x01, 0x01, 0x00,
+ 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
Has this something to do with the SPACE command as defined in SSC-2? I
don't see the code (0x6 here) to be defined. But then you name is rewind.
Yes, we redefine the SPACE based on our need, and named it rewind
+ struct bulk_cb_wrap *bcbw = (struct bulk_cb_wrap *) us-iobuf;
+
+ memset(bcbw, 0, sizeof(struct bulk_cb_wrap));
+ bcbw-Signature = cpu_to_le32(US_BULK_CB_SIGN);
+ bcbw-Tag = 0;
+ bcbw-DataTransferLength = 0;
+ bcbw-Flags = bcbw-Lun = 0;
A memset() followed by an init of each member of the struct. Could please
chose one side?
+ bcbw-Length = sizeof(rewind_cmd);
+ memcpy(bcbw-CDB, rewind_cmd, sizeof(rewind_cmd));
+
+ result = usb_stor_bulk_transfer_buf(us, us-send_bulk_pipe, bcbw,
+ US_BULK_CS_WRAP_LEN, act_len);
I am a little confused here. Shouldn't this be bcbw aka us-iobuf and not
bcbw ?
Yes, you are right.
And shouldn't you read something from the us-recv_bulk_pipe after
that?
Well, because our device will re-connect to switch the ports if it
receives the command.
So it is not necessary to read the response of the command.
+ US_DEBUGP(transfer actual length=%d, result=%d\n, act_len,
result);
+ return result;
+}
+
Sebastian
N�r��yb�X��ǧv�^�){.n�+{��^n�r���z���h��� �G���h�(�階�ݢj���m��z�ޖ���f���h���~�m�
答复: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
-邮件原件- 发件人: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk] 发送时间: 2012年12月14日 17:32 收件人: Fangxiaozhi (Franko) 抄送: linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao 主题: Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command On Fri, 14 Dec 2012 03:01:24 + Fangxiaozhi (Franko) fangxiao...@huawei.com wrote: Dear Alan: This prevents people getting access to the storage device if they want. In our device, after its switching, it will keep the cdrom port together with other ports (such as modem port). So you can access the storage device too, after our switch. Ok so the behaviour is plug in device I am a CD-ROM command sent I am a CD-ROM, I am a modem, I am other things with the newer devices ? Alan Yes, you are right.
RE: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command
Dear Oliver: -Original Message- From: Oliver Neukum [mailto:oneu...@suse.de] Sent: Friday, December 14, 2012 5:34 PM To: Alan Cox Cc: Fangxiaozhi (Franko); linux-usb@vger.kernel.org; linux-ker...@vger.kernel.org; Xueguiying (Zihan); Linlei (Lei Lin); g...@kroah.com; Yili (Neil); Wangyuhua (Roger, Credit); Huqiao Subject: Re: [PATCH 1/1]linux-usb: optimize to match the Huawei USB storage devices and support new switch command On Friday 14 December 2012 09:31:41 Alan Cox wrote: On Fri, 14 Dec 2012 03:01:24 + Fangxiaozhi (Franko) fangxiao...@huawei.com wrote: Dear Alan: This prevents people getting access to the storage device if they want. In our device, after its switching, it will keep the cdrom port together with other ports (such as modem port). So you can access the storage device too, after our switch. Ok so the behaviour is plug in device I am a CD-ROM command sent I am a CD-ROM, I am a modem, I am other things with the newer devices ? For such devices we should put the switching code into generic code, not a device driver so that we have a chance to do reset_resume() on those devices. --Because in many embedded linux system, they don't include such switch tools themselves. So I think it is better to put the switching code in device driver. --By the way, because our device will response the switching command for once, so I think you can do reset_resume() as you want. Regards Oliver Best Regards, Franko Fang
[PATCH 1/1] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com 1. This patch is based on the kernel of 3.6-rc1 2. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi huana...@huawei.com --- --- linux-3.6-rc1/drivers/usb/serial/option.c 2012-08-03 07:38:10.0 +0800 +++ test/linux-3.6-rc1/drivers/usb/serial/option.c 2012-08-08 11:32:15.0 +0800 @@ -80,85 +80,9 @@ #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432 -#define HUAWEI_PRODUCT_E1433 0x1433 -#define HUAWEI_PRODUCT_E1434 0x1434 -#define HUAWEI_PRODUCT_E1435 0x1435 -#define HUAWEI_PRODUCT_E1436 0x1436 -#define HUAWEI_PRODUCT_E1437 0x1437 -#define HUAWEI_PRODUCT_E1438 0x1438 -#define HUAWEI_PRODUCT_E1439 0x1439 -#define HUAWEI_PRODUCT_E143A 0x143A -#define HUAWEI_PRODUCT_E143B 0x143B -#define HUAWEI_PRODUCT_E143C 0x143C -#define HUAWEI_PRODUCT_E143D 0x143D -#define HUAWEI_PRODUCT_E143E 0x143E -#define HUAWEI_PRODUCT_E143F 0x143F #define HUAWEI_PRODUCT_K4505 0x1464 #define HUAWEI_PRODUCT_K3765 0x1465 -#define HUAWEI_PRODUCT_E14AC 0x14AC -#define HUAWEI_PRODUCT_K3806 0x14AE #define HUAWEI_PRODUCT_K4605 0x14C6 -#define HUAWEI_PRODUCT_K5005 0x14C8 -#define HUAWEI_PRODUCT_K3770 0x14C9 -#define HUAWEI_PRODUCT_K3771 0x14CA -#define HUAWEI_PRODUCT_K4510 0x14CB -#define HUAWEI_PRODUCT_K4511 0x14CC -#define HUAWEI_PRODUCT_ETS1220 0x1803 -#define HUAWEI_PRODUCT_E3530x1506 -#define HUAWEI_PRODUCT_E173S
[PATCH 1/8] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com 1. This patch is based on the kernel of 3.5 2. In this patch, we add new micro for matching the series USB devices with vendor ID and interface information. 3. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi huana...@huawei.com --- --- test/linux-3.5/include/linux/usb.h 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/include/linux/usb.h 2012-07-26 14:40:40.0 +0800 @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u .bInterfaceClass = (cl), \ .bInterfaceSubClass = (sc), \ .bInterfaceProtocol = (pr) +/** + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a class of usb interfaces, but independent of product ID + * @vend: the 16 bit USB Vendor ID + * @cl: bInterfaceClass value + * @sc: bInterfaceSubClass value + * @pr: bInterfaceProtocol value + * + * This macro is used to create a struct usb_device_id that matches a + * series of devices with a vendor ID and a specific class of interfaces. + * + * This is especially useful when explicitly matching the specific interface for series of different devices with + * the same vendor. + */ + +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \ + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \ + | USB_DEVICE_ID_MATCH_VENDOR, \ + .idVendor = (vend), \ + .bInterfaceClass = (cl), \ + .bInterfaceSubClass = (sc), \ + .bInterfaceProtocol = (pr) /* --- */ --- test/linux-3.5/drivers/usb/serial/option.c 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/drivers/usb/serial/option.c 2012-07-26 15:51:30.0 +0800 @@ -80,85 +80,9 @@ static void option_instat_callback(struc #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432 0x1432
[PATCH 7/26] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com 1. This patch is based on the kernel of 3.5 2. In this patch, we add new micro for matching the series USB devices with vendor ID and interface information. 3. In this patch, we add new declarations into option.c to support the new interfaces of Huawei Data Card devices. And at the same time, remove the redundant declarations from option.c. Signed-off-by: fangxiaozhi huana...@huawei.com --- --- test/linux-3.5/include/linux/usb.h 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/include/linux/usb.h 2012-07-26 14:40:40.0 +0800 @@ -828,6 +828,27 @@ static inline int usb_make_path(struct u .bInterfaceClass = (cl), \ .bInterfaceSubClass = (sc), \ .bInterfaceProtocol = (pr) +/** + * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a class of usb interfaces, but independent of product ID + * @vend: the 16 bit USB Vendor ID + * @cl: bInterfaceClass value + * @sc: bInterfaceSubClass value + * @pr: bInterfaceProtocol value + * + * This macro is used to create a struct usb_device_id that matches a + * series of devices with a vendor ID and a specific class of interfaces. + * + * This is especially useful when explicitly matching the specific interface for series of different devices with + * the same vendor. + */ + +#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \ + .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \ + | USB_DEVICE_ID_MATCH_VENDOR, \ + .idVendor = (vend), \ + .bInterfaceClass = (cl), \ + .bInterfaceSubClass = (sc), \ + .bInterfaceProtocol = (pr) /* --- */ --- test/linux-3.5/drivers/usb/serial/option.c 2012-07-22 04:58:29.0 +0800 +++ linux-3.5/drivers/usb/serial/option.c 2012-07-26 15:51:30.0 +0800 @@ -80,85 +80,9 @@ static void option_instat_callback(struc #define OPTION_PRODUCT_GTM380_MODEM0x7201 #define HUAWEI_VENDOR_ID 0x12D1 -#define HUAWEI_PRODUCT_E6000x1001 -#define HUAWEI_PRODUCT_E2200x1003 -#define HUAWEI_PRODUCT_E220BIS 0x1004 -#define HUAWEI_PRODUCT_E1401 0x1401 -#define HUAWEI_PRODUCT_E1402 0x1402 -#define HUAWEI_PRODUCT_E1403 0x1403 -#define HUAWEI_PRODUCT_E1404 0x1404 -#define HUAWEI_PRODUCT_E1405 0x1405 -#define HUAWEI_PRODUCT_E1406 0x1406 -#define HUAWEI_PRODUCT_E1407 0x1407 -#define HUAWEI_PRODUCT_E1408 0x1408 -#define HUAWEI_PRODUCT_E1409 0x1409 -#define HUAWEI_PRODUCT_E140A 0x140A -#define HUAWEI_PRODUCT_E140B 0x140B -#define HUAWEI_PRODUCT_E140C 0x140C -#define HUAWEI_PRODUCT_E140D 0x140D -#define HUAWEI_PRODUCT_E140E 0x140E -#define HUAWEI_PRODUCT_E140F 0x140F -#define HUAWEI_PRODUCT_E1410 0x1410 -#define HUAWEI_PRODUCT_E1411 0x1411 -#define HUAWEI_PRODUCT_E1412 0x1412 -#define HUAWEI_PRODUCT_E1413 0x1413 -#define HUAWEI_PRODUCT_E1414 0x1414 -#define HUAWEI_PRODUCT_E1415 0x1415 -#define HUAWEI_PRODUCT_E1416 0x1416 -#define HUAWEI_PRODUCT_E1417 0x1417 -#define HUAWEI_PRODUCT_E1418 0x1418 -#define HUAWEI_PRODUCT_E1419 0x1419 -#define HUAWEI_PRODUCT_E141A 0x141A -#define HUAWEI_PRODUCT_E141B 0x141B -#define HUAWEI_PRODUCT_E141C 0x141C -#define HUAWEI_PRODUCT_E141D 0x141D -#define HUAWEI_PRODUCT_E141E 0x141E -#define HUAWEI_PRODUCT_E141F 0x141F -#define HUAWEI_PRODUCT_E1420 0x1420 -#define HUAWEI_PRODUCT_E1421 0x1421 -#define HUAWEI_PRODUCT_E1422 0x1422 -#define HUAWEI_PRODUCT_E1423 0x1423 -#define HUAWEI_PRODUCT_E1424 0x1424 -#define HUAWEI_PRODUCT_E1425 0x1425 -#define HUAWEI_PRODUCT_E1426 0x1426 -#define HUAWEI_PRODUCT_E1427 0x1427 -#define HUAWEI_PRODUCT_E1428 0x1428 -#define HUAWEI_PRODUCT_E1429 0x1429 -#define HUAWEI_PRODUCT_E142A 0x142A -#define HUAWEI_PRODUCT_E142B 0x142B -#define HUAWEI_PRODUCT_E142C 0x142C -#define HUAWEI_PRODUCT_E142D 0x142D -#define HUAWEI_PRODUCT_E142E 0x142E -#define HUAWEI_PRODUCT_E142F 0x142F -#define HUAWEI_PRODUCT_E1430 0x1430 -#define HUAWEI_PRODUCT_E1431 0x1431 -#define HUAWEI_PRODUCT_E1432
答复: [PATCH 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
Dear bjorn:
Fangxiaozhi (Franko) fangxiao...@huawei.com writes:
From: fangxiaozhi huana...@huawei.com
1. This patch is based on the kernel of 3.5-rc6
2. In this patch, we add new micro for matching the series USB devices with
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices.
Signed-off-by: fangxiaozhi huana...@huawei.com
---
--- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
+0800
+++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
@@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
+/**
+ * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
class of usb interfaces, but independent of product ID
This chunk seems like a copy of the patch Gustavo Padovan just
submitted? Should really be listed as a precondition instead of
included here, should it not?
-In your opinions, it is better to declare this defining in the option.c
file, but not usb.h file, right?
--- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
14:22:52.0 +0800
+++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
@@ -572,6 +572,115 @@ static const struct option_blacklist_inf
};
static const struct usb_device_id option_ids[] = {
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
I guess this means that the device specific entries matching this could
and should be removed, does it not? All these seem redundant with your
patch:
--The new matching rule is independent of the special product ID, so it can
support a series products of Huawei Data Card.
-The following matching rule is only for the specific product, and it is
covered by the new matching rule, so I think that we can remove the following
matching sentences.
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4605,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K5005,
0xff, 0x01, 0x33) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3770,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3771,
0xff, 0x02, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4510,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x31) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4511,
0xff, 0x01, 0x32) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x01) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x02) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x03) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x10) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x12) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x01, 0x13) },
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x01) }, /* E398 3G Modem */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x02) }, /* E398 3G PC UI Interface */
{ USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E353,
0xff, 0x02, 0x03) }, /* E398 3G Application Interface */
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D
[PATCH 7/13] USB:support the new interfaces of Huawei Data Card devices in option driver
From: fangxiaozhi huana...@huawei.com
1. This patch is based on the kernel of 3.5-rc6
2. In this patch, we add new micro for matching the series USB devices with
vendor ID and interface information.
3. In this patch, we add new declarations into option.c to support the new
interfaces of Huawei Data Card devices.
Signed-off-by: fangxiaozhi huana...@huawei.com
---
--- ../test/linux-3.5-rc6/include/linux/usb.h 2012-07-08 08:23:56.0
+0800
+++ include/linux/usb.h 2012-07-13 17:45:59.0 +0800
@@ -828,6 +828,27 @@ static inline int usb_make_path(struct u
.bInterfaceClass = (cl), \
.bInterfaceSubClass = (sc), \
.bInterfaceProtocol = (pr)
+/**
+ * * USB_VENDOR_AND_INTERFACE_INFO - describe a specific usb device with a
class of usb interfaces, but independent of product ID
+ * @vend: the 16 bit USB Vendor ID
+ * @cl: bInterfaceClass value
+ * @sc: bInterfaceSubClass value
+ * @pr: bInterfaceProtocol value
+ *
+ * This macro is used to create a struct usb_device_id that matches a
+ * series of devices with a vendor ID and a specific class of interfaces.
+ *
+ * This is especially useful when explicitly matching the specific interface
for series of different devices with
+ * the same vendor.
+ */
+
+#define USB_VENDOR_AND_INTERFACE_INFO(vend, cl, sc, pr) \
+ .match_flags = USB_DEVICE_ID_MATCH_INT_INFO \
+ | USB_DEVICE_ID_MATCH_VENDOR, \
+ .idVendor = (vend), \
+ .bInterfaceClass = (cl), \
+ .bInterfaceSubClass = (sc), \
+ .bInterfaceProtocol = (pr)
/* --- */
--- ../test/linux-3.5-rc6/drivers/usb/serial/option.c 2012-07-13
14:22:52.0 +0800
+++ drivers/usb/serial/option.c 2012-07-13 17:38:38.0 +0800
@@ -572,6 +572,115 @@ static const struct option_blacklist_inf
};
static const struct usb_device_id option_ids[] = {
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x01) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x02) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x03) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x04) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x05) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x06) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x0F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x10) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x12) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x13) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x14) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x15) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x17) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x18) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x19) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x1C) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x31) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x32) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x33) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x34) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x35) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x36) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3D) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3E) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x3F) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x48) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x49) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4A) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4B) },
+ { USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, 0xff, 0x01, 0x4C) },
+ {
