Hi Colin,
out why. For that I will take a closer look at your USB back-end work and its integration into the kernel.
I have done some investigation into this (see [1]), there is a simple issue and a harder issue.
The simple issue is that for ath9k all control transfers were outgoing, so I simply neglected to support incoming control transfers. That was easily fixed, but exposed the other issue.
The harder issue is that Usb::Packet_handler::submit can block, allowing IO (including timer) signals to be handled. Timer signals in turn can use Lx_kit::Scheduler::schedule to try to run the kernel. Hence, it is a risk to submit any USB transaction from the kernel emulation stack, since this will be a re-entrant call to schedule if it does block and a timer fires. For whatever reason this never happened with ath9k, but seems to happen with rt2800usb. […]
I stumpled across those issues as well ([1], [2]), sorry for not bringing those to your immediate attention - I hope you did not spend too much time chasing them down. To be honest this USB API ('usb/usb.h') should not be used anymore, especially as it contains such stumpling blocks under the hood. You took care to use it a non-blocking fashion but the preferred way is Using the Usb session directly.
(I currently don't have the capacity to give you well-grounded help regarding changing the flow of your LX USB connection which is why I omitted that part of your post.)
Regards Josef