Date: Sat, 03 May 2008 02:32:40 +0200 From: Marcin Cieslak <saper@system.pl> To: freebsd-usb@freebsd.org Subject: Re: sierra wireless compass 597 aircard (Was: Documentation) Message-ID: <fvgbrb$k3u$1@ger.gmane.org> In-Reply-To: <481B5095.8080400@netwolves.com> References: <481B094F.1090408@netwolves.com> <200805021534.13848.hselasky@c2i.net> <481B5095.8080400@netwolves.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCF41D9640639D408450CA286 Content-Type: multipart/mixed; boundary="------------020503050201000804010508" This is a multi-part message in MIME format. --------------020503050201000804010508 Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: quoted-printable Steve Clark wrote: >>> Is there any detailed documentation on the FreeBSD usb device driver = >>> api? This chapter helped me a lot to understand how this all works: http://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/usb.html > I sort of have it working by hacking ubsa.c to look for the sierra=20 > 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 mode= m=20 > mode. > if ( uaa->vendor =3D=3D USB_VENDOR_SIERRA && uaa->product =3D=3D 0x= fff ) It maybe a good idea to add 0xFFF to the usbdevs. Does the "umass" driver attach to the 0xFFF device? I would recommend=20 adding this as a quirk to umass.c then. There are patches attached (ubsa.c_patch, umass_c.patch, usbdevs.patch)=20 I am using to kill the "zeroconf" CD on the UMTS. They do not always=20 work - i.e. umass_attach does not wait until the device is really=20 detached. But setting USB_DEBUG helps :-) > { > ubsa_request_real( sc, 0x0b, 1, 0x40 ); > ucom->sc_dying =3D 1; > goto error; > } > 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.=20 What kind of panic is this? > I think it is related to the sending the > control_message - something is not cleaned up when I "goto error" in th= e=20 > USB_ATTACH function. >=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D121755 There are two patches, one to ohci_pci.c, the other to usb_subr.c. One=20 of them is not correct - after kldunloading the module you may run into=20 problems. But it makes everyday life easier - at least you can remove=20 the card and re-insert. And finally, you will need something to increase your ubsa buffers, I am = using the ubsa.c_buffers_patch attached. (Crude, but cleaner than http://www.freebsd.org/cgi/query-pr.cgi?pr=3D119227) --Marcin --------------020503050201000804010508 Content-Type: text/plain; name="ubsa.c_patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ubsa.c_patch" --- /sys/dev/usb/ubsa.c 2007-06-22 07:56:05.000000000 +0200 +++ ubsa.c 2008-01-03 11:53:09.740739801 +0100 @@ -232,6 +232,8 @@ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GQUAD }, /* Option GlobeTrotter 3G+ */ { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GT3GPLUS }, + /* Option GlobeTrotter Max 3.6 */ + { USB_VENDOR_OPTION, USB_PRODUCT_OPTION_GTMAX36 }, /* Huawei Mobile */ { USB_VENDOR_HUAWEI, USB_PRODUCT_HUAWEI_MOBILE }, { 0, 0 } --------------020503050201000804010508 Content-Type: text/plain; name="umass.c_patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="umass.c_patch" --- /sys/dev/usb/umass.c 2007-07-05 07:26:08.000000000 +0200 +++ umass.c 2008-01-03 11:53:13.592156965 +0100 @@ -323,6 +323,8 @@ * sector number. */ # define READ_CAPACITY_OFFBY1 0x2000 + /* Needs to be initialised the Qualcomm way */ +# define TURNOFF_FLASH 0x4000 }; =20 static struct umass_devdescr_t umass_devdescrs[] =3D { @@ -636,6 +638,10 @@ UMASS_PROTO_SCSI | UMASS_PROTO_BBB, IGNORE_RESIDUE | NO_START_STOP }, + { USB_VENDOR_QUALCOMM2, USB_PRODUCT_QUALCOMM2_MMC, RID_WILDCARD, + UMASS_PROTO_SCSI | UMASS_PROTO_BBB, + TURNOFF_FLASH + }, { USB_VENDOR_SAMSUNG, USB_PRODUCT_SAMSUNG_YP_U2, RID_WILDCARD, UMASS_PROTO_SCSI | UMASS_PROTO_BBB, SHUTTLE_INIT | NO_GETMAXLUN @@ -1027,6 +1033,8 @@ =20 /* quirk functions */ static void umass_init_shuttle (struct umass_softc *sc); +static void umass_turnoff_flash (struct umass_softc *sc); +static void umass_turnoff_flash_cb(struct umass_softc *sc, void *priv, i= nt residue, int status); =20 /* generic transfer functions */ static usbd_status umass_setup_transfer (struct umass_softc *sc, @@ -1472,6 +1480,13 @@ =20 if (sc->quirks & SHUTTLE_INIT) umass_init_shuttle(sc); + if (sc->quirks & TURNOFF_FLASH) { + DPRINTF(UDMASS_USB, ("%s: Detaching MMC\n", + device_get_nameunit(sc->sc_dev))); + umass_turnoff_flash(sc); + umass_detach(self); + return ENXIO; + } =20 /* Get the maximum LUN supported by the device. */ @@ -1576,6 +1591,21 @@ device_get_nameunit(sc->sc_dev), status[0], status[1])); } =20 +static void +umass_turnoff_flash(struct umass_softc *sc) +{ + static uint8_t cmd[] =3D { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00 }; + umass_bbb_transfer(sc, 0, cmd, sizeof(cmd), + NULL, 0, DIR_NONE, 0, + umass_turnoff_flash_cb, NULL); +} + +static void +umass_turnoff_flash_cb(struct umass_softc *sc, void *priv, int residue, = int status) +{ + /* Do nothing */ +} + /* * Generic functions to handle transfers */ --------------020503050201000804010508 Content-Type: text/plain; name="ubsa.c_buffers_patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="ubsa.c_buffers_patch" --- ubsa.c.orig 2008-03-08 04:22:00.333020955 +0100 +++ ubsa.c 2008-03-12 01:20:07.045184146 +0100 @@ -360,15 +360,15 @@ if (UE_GET_DIR(ed->bEndpointAddress) =3D=3D UE_DIR_IN && UE_GET_XFERTYPE(ed->bmAttributes) =3D=3D UE_INTERRUPT) { sc->sc_intr_number =3D ed->bEndpointAddress; - sc->sc_isize =3D UGETW(ed->wMaxPacketSize); + sc->sc_isize =3D 1024; } else if (UE_GET_DIR(ed->bEndpointAddress) =3D=3D UE_DIR_IN && UE_GET_XFERTYPE(ed->bmAttributes) =3D=3D UE_BULK) { ucom->sc_bulkin_no =3D ed->bEndpointAddress; - ucom->sc_ibufsize =3D UGETW(ed->wMaxPacketSize); + ucom->sc_ibufsize =3D 2048; } else if (UE_GET_DIR(ed->bEndpointAddress) =3D=3D UE_DIR_OUT && UE_GET_XFERTYPE(ed->bmAttributes) =3D=3D UE_BULK) { ucom->sc_bulkout_no =3D ed->bEndpointAddress; - ucom->sc_obufsize =3D UGETW(ed->wMaxPacketSize); + ucom->sc_obufsize =3D 2048; } } =20 --------------020503050201000804010508-- --------------enigCF41D9640639D408450CA286 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQCVAwUBSBuyqz2W2v2wY27ZAQM58AQAkH1OC+JIBukTPO+VSQgKB3aB+LZ81umn 6T4Run5isiRsHC4aAKDIpNiGxaINaZf1+Lh2B1wrP/agb7sgoqZBVd7WL8kJv4mP pcQWyNPOa3dhlGGJpjU9q7mcFpKHPRBAHVOJ3+qhsZPY3Yq/gYx4SmXXtSl31iXA oSxRrlW37os= =BWtV -----END PGP SIGNATURE----- --------------enigCF41D9640639D408450CA286--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?fvgbrb$k3u$1>