ath9k usb Wi-Fi driver

[Josef Söntgen]

Hello Colin,

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).

[0] https://github.com/cnuke/genode/commits/pc_wifi_drv-ath9k-2023-01-15

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.

[1] https://github.com/cnuke/genode/commits/ath9k_driver_support-2023-01-15

(As it turned out I might have misremembered as the USB wifi dongle I own
is apparently an Ralink rt2800usb device and not a Realtek one, which
should not matter though.)


> Yes. Regarding splitting up the components, a thought I had was to make the
> 'wifi_supplicant' a separate Genode component. Since it already runs as a
> separate thread using a shared buffer and semaphores, it shouldn't be too
> difficult to split it as its own component. The advantages would be that
> all interfacing of sculpt_manager with the supplicant would be common
> across drivers, making it easier to port more drivers, and each driver
> would inherit the same feature set of the supplicant (e.g. if ad-hoc mode
> were enabled it would not require much, if any, change to the drivers).

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.


> > As you probably have noticed we have some ported USB device drivers, albeit
> > using the legacy lx_kit/lx_emul implementation, that share the glue-code.
> > Eventually we want to update them as well - so by all means, if you have
> > some ideas formed by your current experience feel free to share them.
> >

> Yes, I did see these drivers. My experience with the legacy lx_kit/lx_emul
> implementation has been much less positive than with the current version,
> sorry to say. My thoughts on porting USB drivers:
> […]

Thanks for your input, I will respond to that in time and keep it in mind
only for now.


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/20230116/ca56b175/attachment.sig>