On Monday 26 October 2015 23:38:13 Darren Hart wrote: > My understanding here though is that laptops with a Fn+RBTN key which changes > the state of the radio in firmware should be handled via the rfkill interface > rather than the inpu interface - so while this patch may appear to work, it's > using the input interface to copy the rfkill interface/state. > Here is problem: ACPI device ABCE/RBTN (handled by dell-rbtn.ko) just receive events. It cannot set or change wireless state. For changing rfkill/wireless state is there Dell SMBIOS api and it is implemented in dell-laptop.ko. But due to bugs in that module, it is disabled for XPS machines. And problem is that on machines without HW switch you do not know if wifi switch is in ON or OFF mode. ACPI tell you just "key pressed". So for this reason Alex decided to export that event via input layer, because it is really just key press, not changing state. > The proper solution, if I'm understanding this correctly - and apologies if not, > some of this is new territory for me as well - would be for this device to be > detected as firmware controlled (what we refer to as a SLIDER in the code - > which needs to be renamed IMHO). > I understood that if you blacklist dell-rbtn.ko on that XPS machine, then firmware takes control and automatically turn ON/OFF wifi card. > Let's sort out this point, then we can pull in Rafael to make sure this is how > to best deal with the spurious event on resume. > For me solution (=ignore events when ACPI device is suspended) sounds good. I do not know if there is better way to implement it, maybe general linux device model should provide function "am_i_suspended?" instead tracking "suspend" state internally in each driver. But if such support in linux device or acpi model is not implemented, I'm fine with provided patch if it really works. -- Pali Rohár pali.rohar@xxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html