data endpoints. The control endpoint doesn't need read/write/poll
operations, and more importantly, the thread counts should be
separate so that the control endpoint can properly reference itself
while deleting and recreating the data endpoints.
* Add some macros that handle referencing/releasing devices, and use them
for sleeping/woken-up and open/close operations as apppropriate.
* Use d_purge for FreeBSD, and a loop testing the open status for all
the endpoints for NetBSD and OpenBSD, so that when the device is
detached, the right thing always happens.
restart the current waiting transfer. If this isn't done, the device's
next transfer (that we would like to do a short read on) is going to
return an error -- for short transfer.
* For bulk transfer endpoints, restore the maximum transfer length each
time a transfer is done, or the first short transfer will make all the
rest that size or smaller.
* Remove impossibilities (malloc(M_WAITOK) == NULL, &var == NULL).
to make sure the pipe is ready. Some devices apparently don't support
the clear stall command however. So what happens when you issue such
devices a clear stall command? Typically, the command just times out.
This, at least, is the behavior I've observed with two devices that
I own: a Rio600 mp3 player and a T-Mobile Sidekick II.
It used to be that after the timeout expired, the pipe open operation
would conclude and you could still access the device, with the only
negative effect being a long delay on open. But in the recent past,
someone added code to make the timeout a fatal error, thereby breaking
the ability to communicate with these devices in any way.
I don't know exactly what the right solution is for this problem:
presumeably there is some way to determine whether or not a device
supports the 'clear stall' command beyond just issuing one and waiting
to see if it times out, but I don't know what that is. So for now,
I've added a special case to the error checking code so that the
timeout is once again non-fatal, thereby letting me use my two
devices again.
This changes the naming of USB serial devices to: /dev/ttyU%d and
/dev/cuaU%d for call-in and call-out devices respectively. (Please
notice: capital 'U')
Please also note that we now have .init and .lock devices for USB
serial ports. These are not persistent across device removal. devd(8)
can be used to configure them on attachment time.
These changes also improve the chances of the system surviving if
the USB device is unplugged at an inconvenient time. At least we
do not rip things apart while there are any threads in the device
driver anymore.
Remove cdevsw, rely on the tty generic one.
Don't make_dev(), use ttycreate() which does all the magic.
In detach, do close procesing if we ripped things apart
while the device was open. Call ttyfree() once we're done
cleaning up.
select(2), and discovered to my horror that ugen(4)'s bulk in/out support
is horribly lobotomized. Bulk transfers are done using the synchronous
API instead of the asynchronous one. This causes the following broken
behavior to occur:
- You open the bulk in/out ugen device and get a descriptor
- You create some other descriptor (socket, other device, etc...)
- You select on both the descriptors waiting until either one has
data ready to read
- Because of ugen's brokenness, you block in usb_bulk_transfer() inside
ugen_do_read() instead of blocking in select()
- The non-USB descriptor becomes ready for reading, but you remain blocked
on select()
- The USB descriptor becomes ready for reading
- Only now are you woken up so that you can ready data from either
descriptor.
The result is select() can only wake up when there's USB data pending. If
any other descriptor becomes ready, you lose: until the USB descriptor
becomes ready, you stay asleep.
The correct approach is to use async bulk transfers, so I changed
the read code to use the async bulk transfer API. I left the write
side alone for now since it's less of an issue.
Note that the uscanner driver has the same brokenness in it.
panic on hub detach bugs that have been reported. This work around
detaches the device before deleting it. This changes the detach order
from in-order to pre-order. This avoids uhub's deleting the children
after its subdevs has been deleted.
This is only a workaround. This leads to a strange condition in the
device tree where attached devices are children of detached ones. I
really don't know what that's supposed to mean, but does violate my
sense of POLA. Fortunately, the violation is short lived, which is
why I'm going ahead and committing the work around.
# We really need to consider life w/o the multiple nested layers of
# compatibility macros. They make finding bugs like this *MUCH*
# harder.
Patch by: iadowse
MT5 before: next_release(5.3-BETA5) (unless someting better comes along)
redundant at this point and should be retired). Don't free subdevs if
we don't attach any devices. This was leaving stale device_t's
around. Don't touch the device if it isn't attached since the name
isn't meaningful then. Switch from strncpy (properly used) to
strlcpy.
From a patch submitted by Peter Pentchev
device_t instances when no driver attaches. They are left around, and
we need to remember them.
# The usbd_device_handle->subdevs[] array likely is completely bogus
# at this point, but one change at a time, since its removal will need
# to have similar code replace it extracted from newbus.
Part of the patch submitted by Peter Pentchev after an excellent
analysis of the underlying problems.
MFC After: 1 week
produced better results for a test program I had here, it didn't
substantially change the number of crashes that I saw. Both the old
code and the new code seemed to produce the same crashes from the usb
layer. Since the new code also solves a close() crash, go with it
until the underlying issues wrt devices going away can be addressed.
The reference counts are there to block detach until the sleepers in
read/write/ioctl have gotten out, not to prevent the open device from
going away. Restore the old behavior so that we have a chance to wake
up sleepers when the usb device goes away, so they can properly return
EIO back to the caller when this happens.
Otherwise, we have a guarnateed panic waiting to happen when a device
detaches with an active read channel.
This should be merged to 5 asap.
to RS232 bridges, such as the one found in the DeLorme Earthmate USB GPS
receiver (which is the only device currently supported by this driver).
While other USB to serial drivers in the tree rely heavily on ucom, this
one is self-contained. The reason for that is that ucom assumes that
the bridge uses bulk pipes for I/O, while the Cypress parts actually
register as human interface devices and use HID reports for configuration
and I/O.
The driver is not entirely complete: there is no support yet for flow
control, and output doesn't seem to work, though I don't know if that is
because of a bug in the code, or simply because the Earthmate is a read-
only device.
Without this, the device cannot detect the end of ethernet packets
whose size is a multiple of the USB packat size.
PR: kern/70474
Submitted by: Andrew Thompson <andy@fud.org.nz>
MFC after: 1 week
o reprobe children when a new driver is added to uhub
o fix the usbd_probe_and_attach to set the ivars to a malloc'd area, as well
as freeing the ivars on child destruction.
o Don't delete children that don't attach. Evidentally, the need to do this
is a common misconception.
o minor formatting foo that may violate style(9) at the moment, but keeps the
diffs against my p4 tree smaller.
This does not solve the ugen gobbling things up problem, but the fixes
I have for that expose bugs in other parts of the tree...
if_start routines cannot currently be entered without Giant. When
the kernel is running with debug.mpsafenet != 0, this will defer
if_start execution to a task queue thread holding Giant, which may
introduce additional latency, but avoid incorrect execution.
Suggested by: dfr
skip blocks that are too big by a factor of two or greater. This
avoids some cases of extremely inefficient memory use that can occur
when large (e.g. 64k) blocks on the free list get used when allocating
a 4k chunk of 64-byte fragments. Because fragments have their own
free list, the 60k difference got lost forever every time.
system BIOS to disable legacy device emulation as per the "EHCI
Extended Capability: Pre-OS to OS Handoff Synchronisation" section
of the EHCI spec. BIOSes that implement legacy emulation using SMIs
are supposed to disable the emulation when this procedure is performed.
to be particularly correct or optimal, but it seems to be enough
to allow the attachment of USB2 hubs and USB2 devices connected via
USB2 hubs. None of the split transaction support is implemented in
our USB stack, so USB1 peripherals will definitely not work when
connected via USB2 hubs.
Improve child_detached a little and make it conform better to
style(9). Also, improve comment about what we'll be doing in the
future about driver_added. Soon it will be possible to kldload usb
drivers and have them attach w/o a need to disconnect/reconnect them.
usbdi.c rev. 1.104, author: mycroft
ugen_isoc_rintr() may recycle the xfer immediately. Therefore, we
avoid touching the xfer after calling the callback in
usb_transfer_complete(). From PR 25960.
future:
rename ttyopen() -> tty_open() and ttyclose() -> tty_close().
We need the ttyopen() and ttyclose() for the new generic cdevsw
functions for tty devices in order to have consistent naming.
