From: "Andrew Bird (Sphere Systems)" <ajb@spheresystems.co.uk>
To: linux-kernel@vger.kernel.org
Cc: ajb@spheresystems.co.uk
Subject: Re: Option.c blacklist not functioning as I expected
Date: Wed, 21 Jul 2010 12:53:17 +0100 [thread overview]
Message-ID: <201007211253.18188.ajb@spheresystems.co.uk> (raw)
In-Reply-To: <201007211215.42008.ajb@spheresystems.co.uk>
On Wednesday 21 July 2010, Andrew Bird (Sphere Systems) wrote:
> Guys,
> I wanted to blacklist a network interface that has class 0xff /
> subclass 0xff from the Option usb serial driver for a couple of devices.
> The reason for doing this is I hope to get the usbnet driver running on
> interface 1. The 'blacklist_info' in option.c looked like the way to go,
> but it doesn't seem to have the desired effect, I still get interface 1
> bound. Interfaces 4 and 5 aren't bound but I suspect it's because they are
> storage and not class 0xff.
>
> Please can anyone show me what I'm missing?
>
> Thanks,
>
>
> Andrew
>
> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
> index e280ad8..f1ab07e 100644
> --- a/drivers/usb/serial/option.c
> +++ b/drivers/usb/serial/option.c
> @@ -145,6 +145,8 @@ static void option_instat_callback(struct urb *urb);
> #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 QUANTA_VENDOR_ID 0x0408
> @@ -383,6 +385,14 @@ static const struct option_blacklist_info
> four_g_w14_blacklist = {
> .reason = OPTION_BLACKLIST_SENDSETUP
> };
>
> +/* ignore net, cdrom, sdcard interfaces */
> +static const u8 huawei_k3765_k4505_reserved_if[] = { 1, 4, 5};
> +static const struct option_blacklist_info huawei_k3765_k4505_blacklist = {
> + .infolen = ARRAY_SIZE(huawei_k3765_k4505_reserved_if),
> + .ifaceinfo = huawei_k3765_k4505_reserved_if,
> + .reason = OPTION_BLACKLIST_RESERVED_IF
> +};
> +
> static const struct usb_device_id option_ids[] = {
> { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) },
> { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_RICOLA) },
> @@ -480,6 +490,12 @@ static const struct usb_device_id option_ids[] = {
> { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
> HUAWEI_PRODUCT_E143D, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
> HUAWEI_PRODUCT_E143E, 0xff, 0xff, 0xff) },
> { USB_DEVICE_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID,
> HUAWEI_PRODUCT_E143F, 0xff, 0xff, 0xff) },
> + { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K4505),
> + .driver_info = (kernel_ulong_t)&huawei_k3765_k4505_blacklist
> + },
> + { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_K3765),
> + .driver_info = (kernel_ulong_t)&huawei_k3765_k4505_blacklist
> + },
> { USB_DEVICE(HUAWEI_VENDOR_ID, HUAWEI_PRODUCT_E14AC) },
> { USB_DEVICE(AMOI_VENDOR_ID, AMOI_PRODUCT_9508) },
> { USB_DEVICE(NOVATELWIRELESS_VENDOR_ID,
> NOVATELWIRELESS_PRODUCT_V640) }, /* Novatel Merlin V640/XV620 */
It seems the original urb setup function that called is_blacklisted() has gone
away, here's how it looked
http://www.spinics.net/lists/linux-usb/msg26392.html
To me it looks like urb setup has moved to usb-wwan.c, how should a method to
ignore a specific interface be re-added?
prev parent reply other threads:[~2010-07-21 11:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-21 11:15 Andrew Bird (Sphere Systems)
2010-07-21 11:53 ` Andrew Bird (Sphere Systems) [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201007211253.18188.ajb@spheresystems.co.uk \
--to=ajb@spheresystems.co.uk \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®