usb/92403: uplcom.c needs new entry for 4.00 revision of Prolific chipset

[Marcin Gryszkalis]

>Number:         92403
>Category:       usb
>Synopsis:       uplcom.c needs new entry for 4.00 revision of Prolific chipset
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-usb
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jan 27 04:40:03 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator:     Marcin Gryszkalis
>Release:        6.0-STABLE
>Organization:
fork.pl
>Environment:
>Description:
uplcom.c driver tries to recognize PL2303 chips from PL2303X - unfortunately both can have same product and vendor id. It seems that for USB_VENDOR_PROLIFIC and USB_PRODUCT_PROLIFIC_PL2303 any version >= 3 is PL2303X but the code checks for exact value (0x300). I have an adapter that introduces itself as 4.00 revision.

ucom0: Prolific Technology Inc. USB-Serial Controller C, rev 1.10/4.00, addr 2

# usbdevs -v | grep Pro
 port 1 addr 2: full speed, power 100 mA, config 1, USB-Serial Controller C(0x2303), Prolific Technology Inc.(0x067b), rev 4.00

Quick patch I made (see below) works well but I think some more generic solution is required (It's not fun to add such lines again and again with 4.10, 5.00 revisions if they appear someday). The patch is against uplcom.c 1.30.




>How-To-Repeat:
              
>Fix:
--- uplcom-latest.c     Fri Jan 27 05:20:35 2006
+++ uplcom.c    Fri Jan 27 05:13:53 2006
@@ -238,6 +238,8 @@
        /* ST Lab USB-SERIAL-4 */
        { USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303,
          0x300, TYPE_PL2303X },
+       { USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303,
+         0x400, TYPE_PL2303X },
        /* IOGEAR/ATEN UC-232A (also ST Lab USB-SERIAL-1) */
        { USB_VENDOR_PROLIFIC, USB_PRODUCT_PROLIFIC_PL2303, -1, TYPE_PL2303 },
        /* TDK USB-PHS Adapter UHA6400 */
>Release-Note:
>Audit-Trail:
>Unformatted: