close and re-open the default pipe instead of relying on the host
controller driver to notice the changes. Remove the unreliable code
that attempted to update these fields while the pipe was active.
This fixes a case where the hardware could cache and continue to
use the old address, resulting in a "getting first desc failed"
error.
PR: usb/103167
s/device_ptr_t/device_t/g
No md5 changes in the .o's
# Note to the md5 tracking club: $FreeBSD$ changes md5 after every commit
# so you need to checkout -kk to get $FreeBSD$ instead of the actual value
# of the keyword.
is closed and then reopened. This appears to be necessary now that
we no longer clear endpoint stalls every time a pipe is opened.
Previously we could assume an initial toggle value of zero because
the clear-stall operation resets the device's toggle state.
Reported by: Holger Kipp
MFC after: 3 days
o usb_subr.c, add delta 1.119:
Move usb_get_string() and make it public.
o usbdi.c, bring on par with 1.106, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Whine about not being able to figure out default language if we are debugging.
- Move usb_get_string() and make it public.
o usbdi.h, bring on par with 1.64, this includes:
- Make an iterator abstraction for looping through all descriptors.
- Move usb_get_string() and make it public.
o usbdi_util.c, bring on par with 1.42, this includes:
- Add usbd_get_protocol().
- Use NULL instead of 0.
- Fix (mostly harmless) typo.
- Move utility routine from uirda.c to usbdi_util.c.
o usbdi_util.h, bring on par with 1.31, this includes:
- Add usbd_get_protocol().
- Move utility routine from uirda.c to usbdi_util.c.
MFC after: 3 days
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
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.
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
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...
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
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.
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
descriptor request, which usbd_get_string_desc() uses to get the
length of a descriptor. One device for instance returns a full 8
byte long packet instead which confuses the rest of the stack and
leads to the USB port being reset. The fix is to instead request
two bytes, but not to complain if we only get one.
Submitted by: kan
MFC after: 3 days
date: 2001/08/15 00:04:59; author: augustss;
Add a little infrastructure so that individual drivers can easily check
if thee was a vendor+product locator match.
revision 1.81
date: 2000/10/24 15:01:26; author: augustss; lines: +36 -10
Add a hack to try and figure out if the TI UTUSB41 hub is bus
powered despite claiming to be self powered (it's important to
know so that the power budget can be met).
