> […] 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