The command to get the hub descriptor needs to be a class request and was incorrect causing a Stall error for the hub. The the driver does not handle a stall error yet, causing odd behavior.
Signed-off-by: Jérôme Duval <jerome.duval@gmail.com>
* the CDCE configuration happens to not be the first: iterate the configurations.
* we set the alternate control interface
* queue interrupt requests once opened.
The domains could be deleted by other threads while we were using them
to handle incoming packets, leading to an use after free (deadbeef).
Keep a reference to the doamin as long as we need it so other threads
will not delete them.
Fixes#9721, #12567
At present, does not work (it fails to properly set up interrupts,
resulting in thousands of unhandled ones which all but grinds the system
to a halt) but this at least is some progress.
Since it handles physical address it should really be this.
It's not like many drivers actually used it anyway. It shouldn't harm
compatibility, drivers calling it with only 32bit would leave garbage in
the higher bits but since on x86 it's a noop anyway, it would end up in
the MSB register tha's ignored because it expects a 32bit result.
The reason for the erratic behavior was that the tcp implementation
silently drops window update messages after noting the update but without
triggering any data send event. Before the new TCP patches were applied,
the implementation relied on a retransmission timeout to trigger a send event
after a window update. One of the new patches dealing with the ideal timer
changed the semantic of the restransmit function call and caused the behavior
witnessed.
But a retransmission timeout is not the correct solution to window update. In
fact a retransmission is not a desired effect of window update. So in the patch
attached, I have changed the behavior of the implementation to immediately
acknowledge the window update (along with data from SendQueue) and thus solving
the problem of complete halt in data transmission.
The patch also has the changes re-implemented that were reverted back but had
nothing to do with the issue at hand. For the time being, I have also removed
the "ideal timer" part from the patch (although it wasn't creating any
conflict). I initially decided to implement the ideal timer using the same
timer used for retransmission to avoid adding an additional timer. But as I
have seen, it can be problematic. So I will be re-implementing the ideal timer
and thus it was not included in this patch.
Signed-off-by: Augustin Cavalier <waddlesplash@gmail.com>
Fixes#13704.
FTDI chips send packets of at most 62 bytes of data, with a 2 byte
header. The code assumed that the chip would return at most 64 bytes,
but with new (USB2) chips this is not the case anymore. As a result,
it was skipping only the first header in a packet and leaving the other
ones in the data stream.
Was nothing but a slightly-stripped version of the nvidia driver,
not touched substantially in nearly 10 years, and the cards it was
originally going to support (but never got anywhere near so) have long since
been deprecated.
We had everything in place, except we never actually sent the command to
the device.
Note that the other drivers (prolific, etc) as well as pc_serial need to
be updated as well (might do it when I get access to hardware where I
can test the changes).
