This is part of an ongoing cycle of commits on all the BSDs to
merge the USB vendor and device defintions..
A merge from OpenBSD is still pending.
Submitted by: barry bouwsma (freebsd-misuser@NOSPAM.dyndns.dk)
Obtained from: NetBSD
MFC after: 1 week
to better keep track of the total amoutn transferred during a
transfer. Seems similar to some code in the NetBSD version.
I notice they have incorporated matches from him so I don't know which
direction it went.
Submitted by: damien.bergamini@free.fr
Obtained from: patches to make the ueagle driver work
MFC after: 1 week
Now only things that are different between us and NetBSD show up.
Means that these files are more of NetBSD style in some places but
since thay are NetBSD files, um, that's ok.
Obtained from: NetBSD
MFC after: 1 week
backed out commits were trying to address: when cancelling the timeout
callout, also cancel the abort_task event, since it is possible that
the timeout has already fired and set up an abort_task.
reports of problems. The bug is probably that there are cases where
`xfer->timeout && !sc->sc_bus.use_polling' is not a suitable test
for an active timeout callout, so an explicit flag will be necessary.
Apologies for the breakage.
transfer timeouts that typically cause a transfer to be completed
twice, resulting in panics and page faults:
o A transfer completion interrupt could arrive while an abort_task
event was set up, so the transfer would be aborted after it had
completed. This is very easy to reproduce. Fix this by setting
the transfer status to USBD_TIMEOUT before scheduling the
abort_task so that the transfer completion code will ignore it.
o The transfer completion code could execute concurrently with the
timeout callout, leaving the callout blocked (e.g. waiting for
Giant) while the transfer completion code runs. In this case,
callout_stop() does not prevent the callout from running, so
again the timeout code would run after the transfer was complete.
Handle this case by checking the return value from callout_stop(),
and ignoring the transfer if the callout could not be removed.
o Finally, protect against a timeout callout occurring while a
transfer is being aborted by another process. Here we arrange
for the timeout processing to ignore the transfer, and use
callout_drain() to ensure that the callout has really gone before
completing the transfer.
This was tested by repeatedly performing USB transfers with a timeout
set to approximately the same as the normal transfer completion
time. In the PR below, apparently this occurred by accident with a
particular printer and the default timeout.
PR: kern/71491
just a convenience function to be called from debuggers that gets
compiled in when EHCI_DEBUG is defined. Move its declaration to
make this more obvious.
o Reduce the interrupt delay to 2 microframes.
o Follow the spec more closely when updating the overlay qTD in the QH.
o No need to generate an interrupt at the data part of a control
transfer, it's generated by the status transfer.
o Make sure to update the data toggle on short transfers.
o Turn the printf about needing toggle update into a DPRINTF.
o Keep track of what high speed port (if any) a device belongs to
so we can set the transaction translator fields for the transfer.
o Verbosely refuse to open low/full speed pipes that depend on
unimplemented split transaction support.
o Fix various typos in comments.
Obtained from: NetBSD
asynchronous. I realize that this means the custom application will
not work as written, but it is not okay to break most users of ugen(4).
The major problem is that a bulk read transfer is not an interrupt
saying that X bytes are available -- it is a request to be able to
receive up to X bytes, with T timeout, and S short-transfer-okayness.
The timeout is a software mechanism that ugen(4) provides and cannot
be implemented using asynchronous reads -- the timeout must start at
the time a read is done.
The status of up to how many bytes can be received in this transfer
and whether a short transfer returns data or error is also encoded
at least in ohci(4)'s requests to the controller. Trying to detect
the "maximum width" results in using a single buffer of far too
small when an application requests a large read.
Even if you combat this by replacing all buffers again with the
maximal sized read buffer (1kb) that ugen(4) would allow you to
use before, you don't get the right semantics -- you have to
throw data away or make all the timeouts invalid or make the
short-transfer settings invalid.
There is no way to do this right without extending the ugen(4) API
much further -- it breaks the USB camera interfaces used because
they need a chain of many maximal-width transfers, for example, and
it makes cross-platform support for all the BSDs gratuitously hard.
Instead of trying to do select(2) on a bulk read pipe -- which has
neither the information on desired transfer length nor ability to
implement timeout -- an application can simply use a kernel thread
and pipe to turn that endpoint into something poll-able.
It is unfortunate that bulk endpoints cannot provide the same semantics
that interrupt and isochronous endpoints can, but it is possible to just
use ioctl(USB_GET_ENDPOINT_DESC) to find out when different semantics
must be used without preventing the normal users of the ugen(4) device
from working.
New devicename is ttyy{unit}{port}
No callout devices created as there is no modemcontrol on these ports.
Add data structure to represent each port to avoid excessive array use.
from within umass_ufi_transform(). This includes the 12-byte commands
FORMAT_UNIT, WRITE_AND_VERIFY, VERIFY, and READ_FORMAT_CAPACITIES
(sorted in numerical order).
Reviewed by: ken, scottl
MFC after: 2 weeks
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.
rev. 1.67, author: mycroft
Fix a byte order error.
rev. 1.68, author: mycroft
Adjust some silliness that was causing us to do extra work for
"frame list rollover" interrupts, which we pretty much ignore.
Obtained from: NetBSD
rev. 1.68, author: mycroft
Ignore a port error that happens to come in at the same time as a
connect status change. Some root hubs seem to report both.
Obtained from: NetBSD
bus interfaces. These interfaces use the FTDI chipset with different
Vendor and Product IDs.
Add two additional baud rate enumerations. The vehicle bus interfaces
use a baud rate of 2000000. Also add 3000000 as it is the other FTDI
baud divisor special case.
I've commited a slightly different patch from that provided in the PR as
I changed the matching code a bit yesterday.
Submitted by: Mike Durian <durian at shadetreesoftware.com>
PR: kern/67357
operations when the refcount doesn't protect the opens and closes. Fix
this, and don't actually let a time out happen: now ugen(4) devices do
not get freed out from under the programs with them open.
uhid.c (1.61), author: jdolecek
add support for USB_GET_DEVICEINFO and USB_GET_STRING_DESC ioctls,
with same meaning as for ugen(4)
usbdi_util.h (1.29), usb_quirks.c (1.50), uhid.c (1.62),
ugen.c (1.68), usb_subr.c (1.114) author: mycroft
Yes, some devices return incorrect lengths in their string
descriptors. Rather than losing, do what Windows does: just
request the maximum size, and allow a shorter response. Obsoletes
the need for UQ_NO_STRINGS, and therefore these "quirks" are removed.
usb_subr.c (1.116), author: mycroft
In the "seemed like a good idea until I found the fatal flaw"
department... Attempting to read a maximum-size string descriptor
causes my kue device to go completely apeshit. So, go back to the
original method, but allow the device to return a shorter string than
it claimed.
Obtained from: NetBSD
copies.
No current line disciplines have a dynamically changing hotchar, and
expecting to receive anything sensible during a change in ldisc is
insane so no locking of the hotchar field is necessary.
ohci.c (1.147), author: mycroft
Failure to properly mask off UE_DIR_IN from the endpoint address
was causing OHCI_ED_FORMAT_ISO and EHCI_QH_HRECL to get set
spuriously, causing rather interesting lossage.
Suddenly I get MUCH better performance with ehci...
ohci.c (1.148), author: mycroft
Adjust a couple of comments to make it clear WTF is going on.
Obtained from: NetBSD
ehci.c (1.55), ehcireg.h (1.16); author: mycroft
Set the data toggle correctly, and use EHCI_QTD_DTC. This fixes
problems with my ALi-based drive enclosure (it works now, rather
than failing to attach). Also seems to work with a GL811-based
enclosure and an ASUS enclosure with a CD-RW, on both Intel and
NEC controllers.
Note: The ALi enclosure is currently very SLOW, due to some issue
with taking too long to notice that the QTD is complete. This
requires more investigation.
ehci.c (1.56); author: mycroft
Failure to properly mask off UE_DIR_IN from the endpoint address
was causing OHCI_ED_FORMAT_ISO and EHCI_QH_HRECL to get set
spuriously, causing rather interesting lossage.
Suddenly I get MUCH better performance with ehci...
ehci.c (1.58); author: mycroft
Fix a stupid bug in ehci_check_intr() that caused use to try to
complete a transaction that was still running. Now ehci can
handle multiple devices being active at once.
ehci.c (1.59); author: enami
As the ehci_idone() now uses the variable `epipe'
unconditionally, always declare it (in other words, make this
file compile w/o EHCI_DEBUG).
ehci.c (1.60); author: mycroft
Remove comment about the data toggle being borked.
ehci.c (1.61); author: mycroft
Update comment.
ehci.c (1.62); author: mycroft
Adjust a couple of comments to make it clear WTF is going on.
ehci.c (1.63); author: mycroft
Fix an error in a debug printf().
ehci.c (1.64), ehcireg.h (1.17); author: mycroft
Further cleanup of toggle handling. Now that we use EHCI_QH_DTC,
we don't need to fiddle with the TOGGLE bit in the overlay
descriptor, so minimize how much we fuss with it.
Obtained from: NetBSD
Thanks to Sam for importing tags in a way that allowed this to be done.
Submitted by: Gleb Smirnoff <glebius@cell.sick.ru>
Also allow the sr and ar drivers to create netgraph versions of their modules.
Document the change to the ksocket node.
Several changes:
* Implement read for ulpt.
* If the device is not opened for reading, occasionally drain any
data the printer might have (but don't hammer the printer with reads).
* Lower the buffer size to one page.
The driver seems to work with more printers now.
Obtained from: NetBSD
as otherwise the junk it contains may cause uhub_explore to give
up without ever trying to restart the port. This fixes the following
errors I was seeing with a VIA UHCI controller:
uhub0: port error, restarting port 1
uhub0: port error, giving up port 1
called ttyldoptim().
Use this function from all the relevant drivers.
I belive no drivers finger linesw[] directly anymore, paving the way for
locking and refcounting.
pipes, since open pipes are linked off a usbd_interface structure
that is free()'d when the configuration index is changed. Attempting
to close or use such pipes later would access freed memory and
usually crash the system.
The only driver that is known to trigger this problem is if_axe,
which is itself at fault, but it is worth detecting the situation
to avoid the obscure crashes that result from this type of easily
made driver mistakes.
in all USB ethernet drivers. The qdat structure contains a pointer
to the interface's struct ifnet and is used to process incoming
packets, so simultaneous use of two similar devices caused crashes
and confusion.
The if_udav driver appeared in the tree since Daan's PR, so I made
similar changes to that driver too.
PR: kern/59290
Submitted by: Daan Vreeken <Danovitsch@Vitsch.net>
MFNetBSD 1.177; author: toshii
Use the correct wValue to get hub desriptors.
Also, make wValue checks of root hub codes less strict.
MFNetBSD 1.178: author: martin
Interrupt descriptors might become invalid while being processed in
uhci_check_intr - so remember their next pointer before calling it.
Patch provided by Matthew Orgass in PR kern/24542.
Obtained from: NetBSD
that the OHCI driver uses. Broken OHCI devices (like the controller
in my laptop, apparently) like to set this bit at times. Research
through google shows that this problem has shown up on other systems
as well.
As the scheduling overrun handler doesn't actually do anything, and
the only effect is console spamming, disabling the interrupt seems
to be the right thing to do. (And it is also what linux 2.6 does.)
Introduce d_version field in struct cdevsw, this must always be
initialized to D_VERSION.
Flip sense of D_NOGIANT flag to D_NEEDGIANT, this involves removing
four D_NOGIANT flags and adding 145 D_NEEDGIANT flags.
Add missing D_TTY flags to various drivers.
Complete asserts that dev_t's passed to ttyread(), ttywrite(),
ttypoll() and ttykqwrite() have (d_flags & D_TTY) and a struct tty
pointer.
Make ttyread(), ttywrite(), ttypoll() and ttykqwrite() the default
cdevsw methods for D_TTY drivers and remove the explicit initializations
in various drivers cdevsw structures.
Free approx 86 major numbers with a mostly automatically generated patch.
A number of strategic drivers have been left behind by caution, and a few
because they still (ab)use their major number.
For some very unclear reason this device contains a FTDI 8U232AM USB->COM
adapter, but reports different device id than original 8U232AM. At the same
time, it reports vendor id of FTDI.
Sponsored by: Porta Software Ltd
MFC after: 2 weeks
ubd_devinfo_vp() is getting an empty string from its usbd_get_string()
call on the vendor, instead of NULL. This means usb_knowndevs in not
consulted.
Add lines between grabbing those char *s and the USBVERBOSE ifdef to
set vendor to NULL if it is the empty string (similarly for product).
This causes vendor to be filled-out, although the product name read
overrules usb_knowndevs (this appears to be a conscience decision made
by the NetBSD folks):
PR: kern/56097
Submitted by: Hal Burch <hburch@lumeta.com>
MFC after: 1 week
unmodified for ATAPI type devices with ports/sysutils/cdrtools.
(But we need timeout routine which was in kern/58649 for fixate, I think.)
PR: kern/58649
Submitted by: SAKIYAMA Nobuo <sakichan@sakichan.org>
broken BIOS. Separate ohci_controller_init() from ohci_init(),
and call ohci_controller_init() at resume process once more.
Discussed on [bsd-nomads:16737] - [bsd-nomads:16746].
Submitted by Hiroyuki Aizu <eyes@navi.org> [bsd-nomads:16741]
methods for USB devices in the same way of uhci driver. But this change
is not complete because some ohci controlers are not initialized completely.
So "kernel: usb0: 1 scheduling overruns" interrupt will generate many times.
This change will be same one in PR kern/60099.
Discussed on [bsd-nomads:16737] - [bsd-nomads:16746].
