summaryrefslogtreecommitdiffstats
path: root/sys/dev/usb/uyap.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* "Dr. Jones. Again we see there is nothing you can possess which I cannottedu2014-07-121-137/+0
| | | | | | take away." remove uyap. no effect except on hppa where it was strangely enabled.
* Get rid of various 'typedef struct' definitions and use plain structuremglocker2013-04-151-3/+3
| | | | | | | | | definitions instead. We don't change usb.h for now to stay compatible with userland. Tested by mpi@ on macppc and myself on i386. ok mpi@
* Remove config_activate() and DVACT_ACTIVATE. PCMCIA's the only thingmatthew2011-07-031-4/+1
| | | | | | | | that's ever used it, and it's long since been changed to use DVACT_{QUIESCE,SUSPEND,RESUME} instead. ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it up a few weeks ago
* * add cfattach activate functions and call usbd_deactivate() in thejakemsr2010-12-271-1/+12
| | | | | | | | DVACT_DEACTIVATE case for drivers that don't have activate finctions * fill out cfattach activate functions and call usbd_deactivate() in the DVACT_DEACTIVATE case for drivers that don't have a dying flag "ok with the intent" miod@
* Get rid of devact enum, substitute it with an int and coresponding defines.pirofti2009-10-131-3/+3
| | | | | | This is needed for the addition of further suspend/resume actions. Okay deraadt@, marco@.
* First pass at removing clauses 3 and 4 from NetBSD licenses.ray2008-06-261-8/+1
| | | | | | | | | Not sure what's more surprising: how long it took for NetBSD to catch up to the rest of the BSDs (including UCB), or the amount of code that NetBSD has claimed for itself without attributing to the actual authors. OK deraadt@
* treat usb vendor/product names as a locator, and have usbd_print handle it,deraadt2007-10-111-6/+1
| | | | | | so that it shows up before the :. as a result, all the usb devices do not need to have name printing code anymore. all this now works and prints nicely because usbd_probe_and_attach() is serialized. ok kettenis
* Remove the definition and usage of the USB_DECLARE_DRIVER_CLASS andmbalmer2007-06-141-2/+17
| | | | | | | | USB_DECLARE_DRIVER macros. No binary change. ok dlg.
* Remove the definition and use of the device_ptr_t which was a struct device *.mbalmer2007-06-121-2/+2
| | | | | | No binary change. ok mk.
* Remove the definition and use of the USBDEVNAME macro.mbalmer2007-06-101-5/+5
| | | | | | | (This might look easy, but it was a big diff. Thanks to dlg and especially jsg for looking over it; we found at least four mistakes in the initial diff.) ok jsg.
* Mechanical removal of USBBASEDEVICE. No binary change.mk2007-06-061-2/+2
| | | | | | Tested by thib and myself. ok mbalmer jsg
* Farewell USB_{ATTACH,MATCH,DETACH}* you will not be missed.jsg2007-05-271-13/+12
| | | | ok deraadt@ krw@ mbalmer@
* Don't keep the devinfo string on the stack, instead use malloc/free.brad2005-08-011-4/+6
| | | | | | | | This should cure some rare stack overflows. From augustss NetBSD ok dlg@ pascoe@
* filesystem firmware loading for uyap(4). this should work, i wrote it veryderaadt2004-12-191-19/+26
| | | | | | carefully. unfortunately, we cannot find anyone who has one of these devices in our entire user community, thus far. commit it anyways. whoever finds one can contact me if there is a problem.
* string cleanup; nate okderaadt2003-05-071-2/+2
|
* update $NetBSD$ tagsnate2002-07-251-2/+2
|
* get rid of trailing whitespacenate2002-07-251-4/+4
|
* Make more portable with NetBSDnate2002-05-061-3/+7
| | | | Whitespace sync with NetBSD
* move more microcode, so that it does not end up in /usr/includederaadt2001-12-171-2/+2
|
* Synchronize usb code with NetBSD.nate2001-10-311-4/+4
|
* Add a transient driver for the Y@P phone that downloads firmware intoaaron2001-01-291-0/+114
the EZ-USB chip. After downloading the firmware the device detaches and then reattaches as a composite device (audio + HID). From NetBSD. /* XXX - untested */ Commented out in GENERIC for now, since this sounds like a kind of rare and weird device that no one would have. But it might be useful to have an example driver like this in the tree in case we see more (important) USB devices in the future using the EZ-USB.