ath9k usb Wi-Fi driver

[Colin Parker]

Hi Josef,

I added the ath9k driver [0] to the 'pc_wifi_drv' driver where it worked
> fine in my limited testing (with the one device I have at hand and the
> GSI/MSI quick-fix).
>

Good to hear. Was this done with the changes I made to the supplicant
interface? I'm curious if those break the existing wifi functionality,
which I can't test other than to say it compiles successfully.


> I also started to look at your commits in more detail (I have split them
> up somewhat to get a better grasp of the changes [1] - for the commit in
> world I diff'ed the driver in pc and yours to get your adjustments and
> additions). I noticed that the 'pc_lx_extras' library code seems to be
> missing from your commit.
>
>
At some point I believe this was re-named by me to pc_lx_ath9k_extras. You
should find it in world/lib/mk and the import file in world/lib/import. The
only point as I remember is to add the necessary files from the linux
contrib dir. Since the ath9k driver sits in world, rather than in "pc", the
corresponding source.list and dep.list files are not imported automatically
by pc_linux API, hence the need for the pc_lx_ath9k_extras API for depot
builds, and the import-pc_lx_ath9k_extras file to correctly locate the
imported files. But, I am a genode build/depot build newbie, so perhaps I
made this too complicated? If you want to build in the "pc" repo itself I
suppose it isn't needed.


> I would not go as far as splitting the 'wpa_supplicant' from the driver
> for now. From Sculpt's perspective the wifi-management-layer
> ('Wifi::Frontend') is the interface to talk to. If ad-hoc mode or even
> host-ap functionality becomes a desired feature I would integrate support
> for that in this interface as well.
>
> That being said, I entertain the idea of changing the inner workings
> of the wifi-management ↔ supplicant ↔ driver chain to get rid of the
> internal socket call interface or rather clean it up a bit.
>

Ok, understood. I'm not sure how much cleanup it even needs. As is, I think
it will not be as difficult as I thought to update drivers in the face of
changes to Wifi::Frontend, since basically one just needs to link to a
different version of a shared library. 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.

BTW, were you able to build the wifi_ath9k_drv component? I hope that I
have a version that is suitable for others to try. Well, if anyone has the
hardware, which maybe is not as common as I thought since i bought it a
while ago.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20230116/235bdf01/attachment-0001.htm>