In Openmoko, we're wondering whether we should make the Atheros AR6k
driver register as an rfkill controller or not, and if we do it,
what semantics this should have. I'm looking for advice here.
The issue is that there's no real rfkill hardware in the sense of a
simple switch that cuts power to the transmitter. At least nothing
like this is visible from the kernel. Instead, there is a "fat" and
opaque firmware in the module that decides on such low-level actions
on its own.
There are currently two mechanisms which would fall into the domain
of WLAN APIs that control three operations:
- the possible operations are
1) associate/de-associate with access point
2) scan for access points
3) return -EIO when attempting WLAN ioctls
- when 1) and 2) are applied together, the transmitter is supposed
to be silent
- the mechanisms present so far are
1) SIOCSIWTXPOW
2) an Atheros-specific ioctl (AR6000_IOCTL_EXTENDED, sub-function
AR6000_XIOCTRL_WMI_SET_WLAN_STATE)
- both mechanisms de-associate and stop scanning
- in the case of SIOCSIWTXPOW, setting the ESSID will re-associate
- in the case of AR6000_XIOCTRL_WMI_SET_WLAN_STATE, most ioctls will
return -EIO until another AR6000_XIOCTRL_WMI_SET_WLAN_STATE is
issued that re-enables WLAN
So, first of all, given that TX power is controlled only indirectly
anyway, should we implement rfkill control or not ? There is no kill
switch, so there would be no rfkill input.
If the answer is "yes", would the following semantics be right for
the disabled state ?
- we de-associate
- we stop scanning
- all ioctls still work as usual, but they have no effect on
association and scanning until rfkill re-enables the device
Thanks,
- Werner
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
