On Wed, 11 Jun 2008 20:10:53 +0300, "Tomas Winkler" <tomasw@xxxxxxxxx> said: > Not that I cannot read the code, but what this rkill class actually > should do according your vision? It is not a vision. I am working with what we currently have, and fixing it. It looks like a bit more than a simple code fix, because of the extremely sorry state the documentation for rfkill was (i.e. it was on par with what we have for most of the stuff in the kernel), and the fact that almost nobody really knew how to use rfkill properly given its current limitations (especially the ones existing before my patchset), so you couldn't even find good examples to follow. And there is a lesson here: NOTHING that involves the input layer should ever be merged without a damn complete usage guide to go with it :-) There is no re-designing going on. That could be done later, I suppose, but it is not what I am doing. At most, I am adding a feature here or there. The documentation effort is bringing to light a lot of misconceptions about rfkill and how to use it (and also a lot of its current limitations), and I will address some of these limitations since I am already knee-deep into rfkill right now anyway. > Does it implement radio-state state machine....notification hub for > rfkill switches ... rfkill class: Interface between softswitch and wireless device drivers with the rfkill subsystem. This INCLUDES sysfs and uevents, so it also includes part of the rfkill subsystem interface to userspace. But the rfkill class it is NOT the whole rfkill subsystem, at all. It is only ONE of the interfaces to the rfkill subsystem. There are at least two others: whatever is provided by rfkill-input (which includes processing of input layer events), and whatever is provided by rfkill.h that you can call directly. So, let me repeat it: the rfkill class is just a SUBSET of the rfkill subsystem. > > An example: > > > > ipw4965 probably has two rfkill controls in itself (an input pin for a > > hardkill line, and an R/W IO register to help its driver (ilw4965) implement > > a rfkill softswitch). Those TWO rfkill inputs are to be combined into just > > ONE rfkill class which will be attached to the Linux device provided by > > ilw4965. This is the end of the story from the PoC of the ilw4965 module. > > iwl4965 has actually one more rf kill switch. It switches itself off > if it goes over critical temperature. > For NIC it looks like temporal rfkill. We would just consider that something that looks like another hardkill input line, and be done with it. When you synthesize the rfkill state for ipw4965, you'd use its thermal shutdown status, its hw-rfkill-line input pin status, and its softswitch status (the only one you can control). Everything outside of iwl4965 would still just see a single rfkill status, it doesn't matter how many internal components contributed to that status. -- "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
