device gets removed. However, when the diagnostic check fails,
it is much better to complete the free operation than to abort
it, because this just causes an infinite loop.
From John Nielsen on freebsd-mobile.
Not tested, but almost certainly better than attaching as ugen.
FreeBSD has a UQ_ASSUME_CM_OVER_DATA quirk for this device; I can't
figure out what that means.
Patch by Slava Semushin <slava.semushin@gmail.com>
Again, this was tested by comparing obj files from a pristine and a patched
source tree against an i386/ALL kernel, and also for src/sbin/fsck_ffs,
src/sbin/fsdb and src/usr.sbin/makefs. Only changes in assert() line numbers
were detected in 'objdump -d' output.
in the device status word (at least Palmpilot; comments in Linux
indicate that there are more).
So don't use this information, just use the bit in the configuration
descriptor we are attempting to set. (It is of little use anyway,
perhaps the code can be simplified further.)
Thanks to Steven M. Bellovin for running some tests with a Palmpilot.
exist in newer spec revisions, and is recommended to be set to 1.
So call it _MBO and also use it in the fake root hub descriptors, just
for sanity, even if nothing ever looks at it.
from the attempted power state instead of the real one. The configuration
descriptor is a constant thing and doesn't reflect the actual state, so
this doesn't make any sense. The actual state can be read by a device
status read, so use this as the first and only instance and remove
the device specific quirks which were based on wrong assumptions.
(It is possible that one of the 3 devices with quirk entries still
needs some special treatment, but this would need better research. For
now I'd prefer to avoid a quirk database which isn't maintained anyway.)
Btw, don't be confused by messages about self powered hubs which don't
have external power connected. This is legal, see the specs.
on the number of ports. One byte wasn't even sufficient for 8 ports.
The code doesn't make use of the status bits yet, but it might be used
to speed up the exploration loop later.
when one occured -- this makes that events get lost (or delayed until
the next change), in particular in the handover process from the EHCI
to a companion controller, laeving the port dead under some circumstances.
This fixes the "can't reconnect" symptom for me.
I don't see why the interrupt should be disabled - it is acknowledged
in the interrupt handler and shouldn't be active again until the next
status change.
wsmouse device for now; easy enough to make it a joystick driver in the
future.
Mappings:
Left analog stick: Mouse movement
Right analog stick: Scroll wheel (4 directions)
A button: Left click
B button: Right click
X button: Middle click
Y button: injected to wsmouse as a fourth mouse button click
- finish implementing splraiseipl (and makeiplcookie).
http://mail-index.NetBSD.org/tech-kern/2006/07/01/0000.html
- complete workqueue(9) and fix its ipl problem, which is reported
to cause audio skipping.
- fix netbt (at least compilation problems) for some ports.
- fix PR/33218.
salo