Hi Nils,
Please see inline for my answers.
Nils Goroll wrote:
> Hi Lin,
>
> Lin Guo wrote:
>> I am wondering why you need such a modification. Why not just using
>> the usbVID,PID to attach your driver.
>
> Because this product provides different functions. It changes/switches
> its identity (functions) when a REZERO scsi command is sent to it
> (prtconf -v output reformatted for clarity)
>
> Before switch ("cd-rom emulation")
>
> value='usbaf0,7011.0' + \
> 'usbaf0,7011' + \
> 'usbifaf0,class8.6.50' + \
> 'usbifaf0,class8.6' + \
> 'usbifaf0,class8' + \
> 'usbif,class8.6.50' + \
> 'usbif,class8.6' + \
> 'usbif,class8' + \
> 'usb,device'
>
> After switch ("data mode")
>
> value='usbaf0,7011.0' + \
> 'usbaf0,7011' + \
> 'usbaf0,classff.ff.ff' + \
> 'usbaf0.classff.ff' + \
> 'usbaf0.classff' + \
> 'usb,classff.ff.ff' + \
> 'usb,classff.ff' + \
> 'usb,classff' + \
> 'usb,device'
>
> So the best I could do with the original implementation is to bind a
> driver for the "data mode" to usbaf,classff, but this would also bind
> the driver to other cards of the same vendor which happen to also
> provide a "vendor specific function".
>
> Adding the VID,PID,class identifier seemed to be a straight forward
> improvement.
I see your point. Is it possible to use the following way:
Before switch ("cd-rom emulation")
Bind your driver1 to compatible name "usbifaf0,class8.6.50". The driver1
will send a REZERO scsi command to the device which will be
re-enumerated after receiving the command. ( I suppose that you have a
driver1 for sending the command.)
After switch ("data mode")
Bind your driver2 to compatible name "usbaf0,7011". Then the
"usbaf0,classff.ff.ff" could be used by the "vendor specific function".
The above could be possible since the binding process looks for a match
on the compatible name list from the top name down. As you know, the
compatible name progress from the most specific to the most general.
>
> By the way: I just now realize that the identifiers shown above are
> inconsistent:
>
> 'usbaf0,classff.ff.ff' + \
> 'usbaf0.classff.ff' + \
> 'usbaf0.classff' + \
>
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/usb/usba/usba.c#1967
>
>
>
> uses "usb%x,class%x.%x.%x",
>
> while
>
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/usb/usba/usba.c#1975
>
>
>
> and
>
> http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/uts/common/io/usb/usba/usba.c#1982
>
>
>
> use "usb%x.class%x.%x" and "usb%x.class%x" (NOTE: comma versus dot)
>
> What is the correct form?
Yes, it is a bug. The correct form are "usb%x,class%x.%x" and
"usb%x,class%x". We will fix it soon. Thanks a lot.
In usba.c:
1974 /* 6. usbVID,classDC.DSC */
1975 (void) sprintf(usba_name[n++],
1976 "usb%x.class%x.%x", ---------------------->
That's the problem. It should be "usb%x,class%x.%x".
1976 usb_dev_descr->idVendor,
1976 usb_dev_descr->bDeviceClass,
1976 usb_dev_descr->bDeviceSubClass);
1976
1976 /* 7. usbVID,classDC */
1976 (void) sprintf(usba_name[n++],
1976 "usb%x.class%x",
--------------------------> That's the problem. It should be
"usb%x,class%x".
1976 usb_dev_descr->idVendor,
1976 usb_dev_descr->bDeviceClass);
>
> (UH, and if this is corrected, a patch would probably need to change
> /etc/driver_aliases ...)
The bug doesn't affect /etc/driver_aliases since the compatible name
type "usb%x,class%x.%x" and "usb%x,class%x" haven't be used in Solaris
usb driver binding yet.
>
>> You could get the details of usb binding rule in "Open Firmware
>> Recommended Practice: USB Bus Binding to IEEE Std 1275-1994"
>> which is published on the Internet at:
>> http://playground.sun.com/pub/1275
>> The usb compatible names of Solaris are designed according to it.
>
> Thank you for the pointer, but skimming through some of the documents
> I have only found references to the general BUSvid,pid scheme. Is
> there anything more specific to usb available?
Please check the link for Universal Serial Bus. The link is :
http://playground.sun.com/1275/bindings/usb/usb-1_0.ps
Thanks,
Lin
>
> Thank you,
>
> Nils
