Hi Henrique, > > if the hardware/firmware doesn't allow us to do so, we have no real > > option. I think that nobody thought about this use case so far. I am not > > sure if we should unregister it or just fix rfkill to add an invalid > > state. It is also possible to tie rfkill with ifup/ifdown. > > Please don't register/unregister rfkill classes like that, it is extremely > broken from userspace's point-of-view, and it is not how the rfkill core > subsystem expects things to be used either. If there is no way to avoid > register/unregister at interface up/down, it is better to never register any > rfkill classes at all, and remove the functionality. > > Now, I hate when people use the term "rfkill switch" when dealing with the > kernel rfkill subsystem, because we can't really always be sure we > understood what the person means, so please bear with me... > > Are you talking about the hardware rfkill line (the input pin where one > might have hooked an input device)? Or about something else? so this case is that we are not getting any updates about the rfkill line status if the firmware is not loaded (happens at ifdown case). How do you propose this should be handled? Regards Marcel -- 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
