On Mon, 04 Aug 2008, Tomas Winkler wrote: > > Err, no. If it involves energy emission, if rfkill forbade it [which is to > > be taken as the user forbade it], the driver must not, EVER, cause it to > > happen. There are no exceptions. > > I didn't mean those kind of events :) iwlwifi driver has proper FCC > certification. One thing has nothing to do with the other :) transmitter blocked == energy emission forbidden. I say it like that so that people don't think it is okay to just block data transmission and leave a carrier still being transmitted, or whatever. Remember, rfkill is *generic*, it goes well beyond WiFi. > >> > Sure. I was wondering about drivers that *don't* have it, if any, out of > >> > the potential set of drivers that should be using rfkill (it is not a matter > >> > of those who are using rfkill right now). > >> > >> I think we are aligned in general. > > > > I may still have it as optional, but I will switch the default behaviour > > around. It will likely be useful for someone, and it is less than 10 LOC. > > I make an effort to remove it's a mess. Mess? How so? Anyway, I have been looking at everything that includes linux/rfkill.h. I cannot trust every current in-tree user of rfkill to be shutting down the devices on suspend by just a quick look at their drivers, I just don't know enough about drivers/net/usb/hso or arm/mach-pxa/tosa. I can't even be sure about rt2xxx USB by just looking at the code... So I will ask their maintainers first, instead of trying to guess. Lets see what answers I get. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh -- 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
