Henrique de Moraes Holschuh wrote:
rfkill-input (now) or userspace (someday) will take care of kicking the radio to RFKILL_STATE_UNBLOCKED when (1) issues an event that signals that radios don't have to remain blocked. Maybe this is why you see the WLAN going on when you deactivate the radio kill switch?
It's all done behind the scenes I think (it's an ipw2200 device). There's no rfkill integration from that driver.
And rfkill-input will soon be enhanced to let the user configure it to do something different if he wants. Your driver doesn't (and shouldn't) hardcode policy about it.
Ok, that makes things much easier for me :-) But it means that for now the user will have to manually kick the device.
Thanks. Please take note that rfkill will, right now, try to BLOCK all radios on suspend. That will be changed soon (2.6.28 at the latest), and your driver will have to handle blocking radios on suspend directly if it is needed for toshibas.
Why is this necessary? Doesn't the radio power down as part of the suspend process? How would I tell what the hardware is doing? I'll update the diff when I can. --phil -- 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
