Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1209929 > unrolled thread
| Started by | "Liu.Zhao" <lzsos369@163.com> |
|---|---|
| First post | 2015-08-19 18:10 +0200 |
| Last post | 2015-08-24 14:40 +0200 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[PATCH v3 1/1] USB:option:add ZTE PIDs "Liu.Zhao" <lzsos369@163.com> - 2015-08-19 18:10 +0200
Re: [PATCH v3 1/1] USB:option:add ZTE PIDs Johan Hovold <johan@kernel.org> - 2015-08-24 09:30 +0200
Re: [PATCH v3 1/1] USB:option:add ZTE PIDs Bjørn Mork <bjorn@mork.no> - 2015-08-24 10:00 +0200
Re: [PATCH v3 1/1] USB:option:add ZTE PIDs Johan Hovold <johan@kernel.org> - 2015-08-24 14:40 +0200
| From | "Liu.Zhao" <lzsos369@163.com> |
|---|---|
| Date | 2015-08-19 18:10 +0200 |
| Subject | [PATCH v3 1/1] USB:option:add ZTE PIDs |
| Message-ID | <pZe65-2qB-7@gated-at.bofh.it> |
This is intended to add ZTE device PIDs on kernel.
Signed-off-by: Liu.Zhao <lzsos369@163.com>
---
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Johan Hovold <johan@kernel.org> |
|---|---|
| Date | 2015-08-24 09:30 +0200 |
| Message-ID | <q0UmB-SN-13@gated-at.bofh.it> |
| In reply to | #1209929 |
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 <lzsos369@163.com>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Bjørn Mork <bjorn@mork.no> |
|---|---|
| Date | 2015-08-24 10:00 +0200 |
| Message-ID | <q0UPE-1qY-9@gated-at.bofh.it> |
| In reply to | #1211857 |
Johan Hovold <johan@kernel.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Johan Hovold <johan@kernel.org> |
|---|---|
| Date | 2015-08-24 14:40 +0200 |
| Message-ID | <q0ZcD-7Np-15@gated-at.bofh.it> |
| In reply to | #1211876 |
On Mon, Aug 24, 2015 at 09:51:33AM +0200, Bjørn Mork wrote:
> Johan Hovold <johan@kernel.org> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web