[Libdlo] [PATCH] udlfb: Restrict device id match on composite devices

[Bernie Thompson]

Hi Andrew,

Thanks for submitting this patch!

On Thu, Dec 9, 2010 at 11:45 AM, Andrew Kephart <akephart at akephart.org> wrote:
> Hi all.
>
> I noticed that udlfb was getting bound to the audio and HID interfaces
> of my DL-based composite device, so here's a patch that incorporates the
> interface class into the match (since the DisplayLink interface proper
> always uses a vendor-specific class).

Can you say what hardware you're using?  Is this one of the
DisplayLink HDMI designs with integrated audio?

> I'm not sure if this is entirely the correct solution, but it seems to
> work.

Yes, this area is very tricky. We need to think about a number of
DisplayLink USB 2.0 design variations (normal, composite with HID or
audio+HID, and multi-configuration for the purposes of driver install
off of flash), plus we have the unknowns of USB 3.0 devices arriving
in coming months.

> What do you folks think?

First blush, I think this is a safe change, and I assume something
like this is needed for the HDMI graphics+audio solutions. I'd be
interested if anyone else see any problems.  Of course, this doesn't
solve our USB 3.0/DL next-gen vs. generic VID match dilemmas.

I'll run the change with some of the DisplayLink hardware variants I
have here.  If no red flags come up, I expect we'll take this patch
and get it pushed downstream into the kernel.

Again, thank you!
Bernie
http://plugable.com/

> -andrew
>
> ==================8<=================================
>
> Restrict match to vendor-specific interfaces of composite DisplayLink
> devices
>
> For composite devices with DisplayLink vid, udlfb is matching the non-DL
> interfaces (audio, HID, etc.) as well as the primary video interface
> (vendor-specific class).  This patch incorporates the interface class
> as part of the device id match.
>
>
> diff --git a/udlfb.c b/udlfb.c
> index 59a1925..7b6aa27 100644
> --- a/udlfb.c
> +++ b/udlfb.c
> @@ -50,11 +50,14 @@ static const u32 udlfb_info_flags = FBINFO_DEFAULT |
> FBINFO_READS_FAST |
>  /*
>  * There are many DisplayLink-based products, all with unique PIDs. We
> are able
>  * to support all volume ones (circa 2009) with a single driver, so we
> match
> - * globally on VID. TODO: Probe() needs to detect when we might be
> running
> + * globally on VID, but select only the interfaces that have
> vendor-specific
> + * class designations.
> + *
> + * TODO: Probe() needs to detect when we might be running
>  * "future" chips, and bail on those, so a compatible driver can match.
>  */
>  static struct usb_device_id id_table[] = {
> -       {.idVendor = 0x17e9, .match_flags =
> USB_DEVICE_ID_MATCH_VENDOR,},
> +       {.idVendor = 0x17e9, .bInterfaceClass = 0xFF , .match_flags =
> USB_DEVICE_ID_MATCH_VENDOR|USB_DEVICE_ID_MATCH_INT_CLASS,},
>        {},
>  };
>  MODULE_DEVICE_TABLE(usb, id_table);
>