We currently have 26 wifi drivers in the source tree. A few of them have already been converted for the wifi renewal branch (see Wifi renewal on hg, Converting drivers to the new wifi stack, and Converting USB drivers to usbwifi(9).).

Device at usbwifi converted tested
an pci, pcmcia[1], isapnp - no no
ath pci[1], cardbus[1] - no no
athn pci[1], cardbus, usb[1] +/-/? no no
atu usb[1] + no no
atw pci, cardbus[1] - no no
awi pcmcia - no no
bwfm pci, sdmmc[1], usb[1] +/-/? no no
bwi pci, cardbus[1] - no no
ipw pci - yes no
iwi pci - no no
iwm pci[1] - yes ?
iwn pci[1] - yes ?
malo pci - no no
otus usb[1] + no no
ral pci, cardbus[1] +/-/? no no
rtw pci, cardbus[1] - no no
rtwn pci[1] - yes yes
rum usb[1] + no no
run usb[1] + no no
upgt usb[1] + no no
ural usb[1] + no no
urtw usb[1] + no no
urtwn usb[1] + yes yes
wi pci, pcmcia[1] - no no
wpi pci - no no
zyd usb[1] + no no

[1] = Martin has hardware in testable condition

usbwifi = + means: the driver will be converted to usbwifi, which is an easy conversion

usbwifi = +/-/? means: at this point it is not clear if the driver (or parts of it) will be able to use usbwifi, the bus frontend vs. backend driver split has to be reviewed to analyze if usbwifi is feaseable/practical and an improvement over manual conversion.

Currently the drivers for urtwn(4) and rtwn(4) are converted, the former using usbwifi (see Converting USB drivers to usbwifi(9)), but it is not clear if there is a unified aproach that lets the usb frontend profit from usbwifi while not stopping the usb and the other frontends from sharing most parts of the driver - this still has to be evaluated.

Other drivers sharing similar chipsets accross different busses including usb have not yet been converted, they are marked with +/-/? in the usbwifi column of above table.

Looking for hardware

For every chipset without a [1] mark in the table above, I am looking for hardware: