Henrique de Moraes Holschuh wrote: > You want the rfkill core to track per-device-instance rfkill states, or > would the per-type tracking it does already be enough? This is a good question :-) As long as we're only concerned with making sure no RF power goes into the air, even a global switch for all RF devices may be sufficient. There may also be cases where only certain bands or signal strenghts are prohibited. E.g., BT may be tolerated while GSM isn't. The current rfkill architecture covers this. At the other end of the spectrum you have people who use rfkill as a poor man's power management. These would definitely want a more fine-grained control. There may be more usage stories, with yet different requirements. I think may uneasiness with the current situation comes mainly from having an unreliable per-device rfkill control. You can switch it on or off, but whether this setting lasts across suspend/resume depends on the implementation. There's also a contradiction with rfkill.txt, section 3.1, bullet 6: "During resume, rfkill will try to restore its previous state." But I think the per-type controls could in fact be good enough for all practical purposes. In the worst case, a dedicated controller could just turn everything off and activate things on a case-by-case basis. But then we're a few sysfs interfaces short. Is there any specific reason why there is a control for setting the global default state (/sys/module/rfkill/parameters) but there are no controls for: - setting the default state by type, - setting the current state by type, and - setting the current state ? > But there are other questions: why? You *NEED* somewhere to attach the > rfkill kobjects to, and that somewhere can't very well be a device that is > getting hotunplugged, as it will disappear. So, you will need something > like the platform device you used, anyway... In my scenario, a driver calling rfkill_detach would say "I might be back". But I think I like the idea of making the per-type controls more powerful. - 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
