sclark at netwolves.com
Fri May 2 17:34:15 UTC 2008
Hans Petter Selasky wrote:
> On Friday 02 May 2008, Steve Clark wrote:
>>Is there any detailed documentation on the FreeBSD usb device driver api?
>>freebsd-usb at freebsd.org mailing list
>>To unsubscribe, send any mail to "freebsd-usb-unsubscribe at freebsd.org"
> For the usb.p4 there is a README. Else you have to look at the existing USB
Well here is my problem. I am trying to get a sierra wireless 597 evdo
usb modem to work with
freebsd 6.1. The usb device when it is first plugged in has a product
id of 0xfff and looks like a
cdrom drive with software drivers on it for Windows. It has to have a
control message sent to it
to put it in modem mode.
I sort of have it working by hacking ubsa.c to look for the sierra
vendor id and product id of 0xfff in
the usb_match function and return match. Then in the usb_attach code I
look again for the vendor and
product id of 0xfff and then send the control message to put it in
if ( uaa->vendor == USB_VENDOR_SIERRA && uaa->product == 0xfff )
ubsa_request_real( sc, 0x0b, 1, 0x40 );
ucom->sc_dying = 1;
This puts in modem mode with product id of 0x0023 which i have plugged
into usbdevs and also put in ubsa.c
so now I get a ucom device and can successfully run ppp. The problem I
am running into now is sometime after
it remove the device I will get a page fault panic in the kernel. I
think it is related to the sending the
control_message - something is not cleaned up when I "goto error" in
the USB_ATTACH function.
I modified ubsa_reguest() to accept a request_type and called it
ubsa_request_real() and then had
ubsa_request() call ubsa_request_real as
return (ubsa_request_real( sc, request, value, UT_WRITE_VENDOR_DEVICE ));
Now that I looked up what UT_WRITE_VENDOR_DEVICE is I guess this was
an unnecessary step.
Any ideas how this should really be handled - That sending the control
message to put the device in
More information about the freebsd-usb