I'd like to restart a discussion from last year, namely how aggressive an rfkill implementation is allowed to be when it comes to destroying MAC state. The design suggested in rfkill.txt and also implemented in the existing drivers basically assumes a simple on/off switch that cuts power to the transmitter but doesn't change anything else. The question is if this is already the full extent to which rfkill is allowed to affect MAC state or if it could go further. In the AR6k, we don't have such a simple switch for the transmitter. We can control what the transmitter does very indirectly by temporarily reconfiguring the MAC, but this creates a fair amount of complexity, which also seems to be at odds with the design of rfkill. Alternatively, we could just power down the whole WLAN module. That is easily done and very reliable. However, MAC state (ESSID, keys, and a host of other settings) is obliterated if we do this. A watchful user space (e.g., wpa_supplicant) could then restore the status quo ante. Now the question is whether this is still in the spirit of the design of rfkill of if it would take things too far. It seems that there is no consensus on this issue yet. I started the implementation with the assumption that rfkill should always behave as if it only cut transmitter power, so no other state of the MAC is allowed to be lost. This is also what Henrique suggested I should do. However, Andy and recently Michael suggested that, given that an interface that has no connectivity for an extended period of time is likely to get reconfigured anyway, it may be sufficient if rfkill leaves things in a state that allows user space to restore connectivity, without having to worry about details beyond that. rfkill.txt only specifies the minimum actions an RF kill is required to perform, but it's silent on how far it is allowed to go. Let's fix this :-) 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
