too, but that's not critical): real hubs send port status change
notifications until acknowledged, ehci/ohci send only once so there is
a chance that this gets lost if notifications are disabled during a scan.
The temporary fix is to force a rescan; the real fix will involve a
change in interrupt handling in ehci/ohci which needs more work and
testing.
ehci is critical because a port status change during scan regularely
happens if a full/lowspeed device is connected, due to the handover
process.
Fixes a problem where full/lowspeed devices were not reattached after
a disconnect, reported by Kouichirou Hiratsuka and Juan RP
on current-users.
through the interrupt pipe; during exploration check only the ports
where we got such a notification. This speeds up things.
(I believe we should go a step further and use a thread per hub
instead of per bus. If power management gets implemented, we should
be able to react quickly on a resume event.)
Try to simplify the logics in the explore function a bit. (The reattach
thing was hacked in badly, not sure whether I broke it. Only used
by if_atu.)
Clean up some dead code.
matching (and handling) a whole device and those which match an
interface only. This will allow to enforce some rules, eg that
the former don't use interface information for matching or that the
latter don't modify global device state.
The previous way left too much freedom do the drivers which led to
inconsistencies and abuse.
For now, I've not changed locators and submatch rules, this will
happen later.
There should not be any change in behaviour, except in the case of
some drivers which did behave inconsistently:
if_atu, if_axe, uep: matched the configured device in the interface
stage, but did configuration again. I've converted them to match
in the device stage.
ustir, utoppy: matched in the interface stage, but only against
vendor/device information, and used any configuration/interface
without checking. Changed to match in device stage, and added
some simple code to configure and use the first interface.
If you have one of those devices, please test!
bus powered hub. While one can interpret the spec that way, it is not
stated clearly, and is at most a side effect of power budgeting.
Also, there are devices which don't report correctly whether they
are self powered, so the check was unreliable.
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.
than allocating memory, and it does wrongly use the hub's capabilities
but not the actual setting
-switch a high-speed hub to "multiple TTs" but ignore errors; since
we don't care whether there is one or multiple this is a "best effort"
thing
set the transaction translator fields for the transfer.
Add a gross hack for split transaction completion in the ehci driver that
allows control transfers to be translated. Interrupt transfers do not work.
Warn when any low/full speed device is opened.
USB device discovery, now it can also perform (short) tasks for device
drivers that need a process context, but don't have one.
This is not pretty, but better than using busy-wait in an interrupt context.
Windoze more closely. This makes more devices work.
After two years of doing USB work I've finally access to a USB protocol
analyzer. Which means I should be able to mimic what Windoze does in
certain cases instead of just following the specs. Following the specs
is not enough since the devices often don't.
