ath9k usb Wi-Fi driver

[Josef Söntgen]

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

-- 
Josef Söntgen
Genode Labs

http://www.genode-labs.com/ · http://genode.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.genode.org/pipermail/users/attachments/20230330/de49c9f2/attachment.sig>