2015-08-19 16:07:35

by Liu.Zhao

Subject: [PATCH v3 1/1] USB:option:add ZTE PIDs

This is intended to add ZTE device PIDs on kernel.



Signed-off-by: Liu.Zhao <[email protected]>
---
drivers/usb/serial/option.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)

diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index 876423b..e26db28 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -278,13 +278,17 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MF622 0x0001
#define ZTE_PRODUCT_MF628 0x0015
#define ZTE_PRODUCT_MF626 0x0031
-#define ZTE_PRODUCT_AC2726 0xfff1
-#define ZTE_PRODUCT_MG880 0xfffd
-#define ZTE_PRODUCT_CDMA_TECH 0xfffe
-#define ZTE_PRODUCT_AC8710T 0xffff
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_MBIM 0x0426
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
#define ZTE_PRODUCT_MC2718 0xffe8
#define ZTE_PRODUCT_AD3812 0xffeb
#define ZTE_PRODUCT_MC2716 0xffed
+#define ZTE_PRODUCT_AC2726 0xfff1
+#define ZTE_PRODUCT_MG880 0xfffd
+#define ZTE_PRODUCT_CDMA_TECH 0xfffe
+#define ZTE_PRODUCT_AC8710T 0xffff

#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,14 @@ static const struct option_blacklist_info zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};

+static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
+
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1581,16 +1593,24 @@ static const struct usb_device_id option_ids[] = {
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfff9, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffb, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffc, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T, 0xff, 0xff, 0xff) },
- { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff),
- .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&zte_ad3812_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 0xff, 0xff, 0xff),
.driver_info = (kernel_ulong_t)&zte_mc2716_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff),
+ .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 0xff, 0xff) },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+ .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+ .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+ .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+ .driver_info = (kernel_ulong_t)&zte_me3620_mbim_blacklist },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
--
1.9.1

2015-08-24 07:26:49

by Johan Hovold

Subject: Re: [PATCH v3 1/1] USB:option:add ZTE PIDs

On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
>
> This is intended to add ZTE device PIDs on kernel.
>
>
>
> Signed-off-by: Liu.Zhao <[email protected]>
> ---
> drivers/usb/serial/option.c | 36 ++++++++++++++++++++++++++++--------
> 1 file changed, 28 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index 876423b..e26db28 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -278,13 +278,17 @@ static void option_instat_callback(struct urb *urb);
> #define ZTE_PRODUCT_MF622 0x0001
> #define ZTE_PRODUCT_MF628 0x0015
> #define ZTE_PRODUCT_MF626 0x0031
> -#define ZTE_PRODUCT_AC2726 0xfff1
> -#define ZTE_PRODUCT_MG880 0xfffd
> -#define ZTE_PRODUCT_CDMA_TECH 0xfffe
> -#define ZTE_PRODUCT_AC8710T 0xffff
> +#define ZTE_PRODUCT_ZM8620_X 0x0396
> +#define ZTE_PRODUCT_ME3620_MBIM 0x0426
> +#define ZTE_PRODUCT_ME3620_X 0x1432
> +#define ZTE_PRODUCT_ME3620_L 0x1433
> #define ZTE_PRODUCT_MC2718 0xffe8
> #define ZTE_PRODUCT_AD3812 0xffeb
> #define ZTE_PRODUCT_MC2716 0xffed
> +#define ZTE_PRODUCT_AC2726 0xfff1
> +#define ZTE_PRODUCT_MG880 0xfffd
> +#define ZTE_PRODUCT_CDMA_TECH 0xfffe
> +#define ZTE_PRODUCT_AC8710T 0xffff

Reordering the current entries is not needed, but if you do it then you
must mention it in the commit message above.

Also make sure to not change any formatting; checkpatch is now
complaining about whitespace issues (always run checkpatch before
submitting).

> #define BENQ_VENDOR_ID 0x04a5
> #define BENQ_PRODUCT_H10 0x4068
> @@ -544,6 +548,14 @@ static const struct option_blacklist_info zte_mc2716_z_blacklist = {
> .sendsetup = BIT(1) | BIT(2) | BIT(3),
> };
>
> +static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = {
> + .reserved = BIT(3) | BIT(4) | BIT(5),
> +};

Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
even if they reserve the same ports.

> +
> +static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
> + .reserved = BIT(2) | BIT(3) | BIT(4),
> +};
> +
> static const struct option_blacklist_info huawei_cdc12_blacklist = {
> .reserved = BIT(1) | BIT(2),
> };
> @@ -1581,16 +1593,24 @@ static const struct usb_device_id option_ids[] = {
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfff9, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffb, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xfffc, 0xff, 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC2726, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AC8710T, 0xff, 0xff, 0xff) },
> - { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff),
> - .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_AD3812, 0xff, 0xff, 0xff),
> .driver_info = (kernel_ulong_t)&zte_ad3812_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_CDMA_TECH, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2716, 0xff, 0xff, 0xff),
> .driver_info = (kernel_ulong_t)&zte_mc2716_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MC2718, 0xff, 0xff, 0xff),
> + .driver_info = (kernel_ulong_t)&zte_mc2718_z_blacklist },
> + { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, ZTE_PRODUCT_MG880, 0xff, 0xff, 0xff) },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
> + .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
> + .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
> + .driver_info = (kernel_ulong_t)&zte_me3620andzm8620_xl_blacklist },
> + { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
> + .driver_info = (kernel_ulong_t)&zte_me3620_mbim_blacklist },

If really want to reorder the current entries, then at least make sure
the end result is indeed sorted.

> { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
> { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
> { USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },

Johan

2015-08-24 07:52:31

by Bjørn Mork

Subject: Re: [PATCH v3 1/1] USB:option:add ZTE PIDs

Johan Hovold <[email protected]> writes:
> On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
>>
>> #define BENQ_VENDOR_ID 0x04a5
>> #define BENQ_PRODUCT_H10 0x4068
>> @@ -544,6 +548,14 @@ static const struct option_blacklist_info zte_mc2716_z_blacklist = {
>> .sendsetup = BIT(1) | BIT(2) | BIT(3),
>> };
>>
>> +static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = {
>> + .reserved = BIT(3) | BIT(4) | BIT(5),
>> +};
>
> Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
> even if they reserve the same ports.

Why? Wouldn't it be better to merge all identical lists and give them
structured names describing their contents instead? E.g.

static const struct option_blacklist_info bi_s0001_r = {
.sendsetup = BIT(0) | BIT(1),
};

static const struct option_blacklist_info bi_s0001_r04 = {
.sendsetup = BIT(0) | BIT(1),
.reserved = BIT(4),
};

static const struct option_blacklist_info bi_s_r030405 = {
.reserved = BIT(3) | BIT(4) | BIT(5),
};


etc. Or some other naming scheme.

I don't see the point of having lots of identical structs just to be
able to name them after some rarely meaningful marketing name. Many
vendors recycle their pids, making this completely futile.


Bjørn

2015-08-24 12:31:27

by Johan Hovold

Subject: Re: [PATCH v3 1/1] USB:option:add ZTE PIDs

On Mon, Aug 24, 2015 at 09:51:33AM +0200, Bj?rn Mork wrote:
> Johan Hovold <[email protected]> writes:
> > On Wed, Aug 19, 2015 at 08:51:17AM -0700, Liu.Zhao wrote:
> >>
> >> #define BENQ_VENDOR_ID 0x04a5
> >> #define BENQ_PRODUCT_H10 0x4068
> >> @@ -544,6 +548,14 @@ static const struct option_blacklist_info zte_mc2716_z_blacklist = {
> >> .sendsetup = BIT(1) | BIT(2) | BIT(3),
> >> };
> >>
> >> +static const struct option_blacklist_info zte_me3620andzm8620_xl_blacklist = {
> >> + .reserved = BIT(3) | BIT(4) | BIT(5),
> >> +};
> >
> > Use two structs for this: zte_me3620_blacklist and zm8620_xl_blacklist
> > even if they reserve the same ports.
>
> Why?

To avoid including every device family in the symbol name (and we
already have duplicate blacklist definitions).

> Wouldn't it be better to merge all identical lists and give them
> structured names describing their contents instead?

It certainly would.

> E.g.
>
> static const struct option_blacklist_info bi_s0001_r = {
> .sendsetup = BIT(0) | BIT(1),
> };
>
> static const struct option_blacklist_info bi_s0001_r04 = {
> .sendsetup = BIT(0) | BIT(1),
> .reserved = BIT(4),
> };
>
> static const struct option_blacklist_info bi_s_r030405 = {
> .reserved = BIT(3) | BIT(4) | BIT(5),
> };
>
>
> etc. Or some other naming scheme.

Perhaps bi_s<setup_mask>_r<reserved_mask> (e.g. bi_s3_r0, bi_s3_r10, and
bi_s0_r38 for the above) would be too compact?

> I don't see the point of having lots of identical structs just to be
> able to name them after some rarely meaningful marketing name. Many
> vendors recycle their pids, making this completely futile.

I agree. Let's just decide on a naming scheme first.

Johan