ath9k usb Wi-Fi driver
Colin Parker
cvparker at gmail.com
Tue Jan 24 04:55:23 CET 2023
Josef,
> […] Admittedly I was also thinking of some unusual scenarios, such as
> > multiple wifi adapters where it makes sense to have one supplicant and
> > multiple drivers. But that's strange enough maybe it doesn't need to
> > be supported.
>
> At least from my perspective I would rather treat the supplicant as a
> “minor” detail of the driver itself. So each instance has its own
> supplicant and a management component could take care of the overall
> configuration on the system level for multiple wireless devices.
>
>
Ok, I guess that makes sense.
> However, I enabled the RT2800USB driver [0], added a 'wifi_ath9k.run'
> run script based on 'pc/run/wifi.run' to ease testing and will use this
> for further testing and development before tackling the Sculpt
> integration.
Ok, I may give this a look with the ath9k that I have already, it could be
a great help in reducing compile time versus the depot builds.
> I also had to adapt the test-bed somewhat [1] as the driver
> still requires the Platform session - removing this hard dependency is
> one of the tasks I implied by the PCI/USB split.
>
I'm not quite sure why this is for RT2800, it was not necessary for ath9k?
> So far the RT2800USB driver is non-working and the next step is figuring
> out why. For that I will take a closer look at your USB back-end work
> and its integration into the kernel.
>
Bummer. I may pick one up too (i.e. RT2800-based device), they don't look
pricey.
>
> (Bare with me as this is done in my spare time, it might take a while.)
>
Sure, same.
-CVP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20230123/393d373a/attachment.htm>
More information about the users
mailing list