2015-10-22 9:49 GMT+02:00 Darren Hart <dvhart@xxxxxxxxxxxxx>: > On Wed, Oct 21, 2015 at 08:53:36PM +0200, Gabriele Mazzotta wrote: >> 2015-10-21 13:42 GMT+02:00 Gabriele Mazzotta <gabriele.mzt@xxxxxxxxx>: >> > 2015-10-21 13:12 GMT+02:00 Darren Hart <dvhart@xxxxxxxxxxxxx>: >> >> On Wed, Oct 21, 2015 at 01:00:59PM +0200, Pali Rohár wrote: >> >>> On Wednesday 21 October 2015 11:19:54 Pali Rohár wrote: >> >>> > On Wednesday 21 October 2015 10:57:24 Darren Hart wrote: >> >>> > > On Sun, Oct 18, 2015 at 09:34:56AM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: >> >>> > > > https://bugzilla.kernel.org/show_bug.cgi?id=106031 >> >>> > > > >> >>> > > > --- Comment #2 from Britt Yazel <bwyazel@xxxxxxxxx> --- >> >>> > > > Confirmed. Blacklisting the dell_rbtn module solves this issue >> >>> > > >> >>> > > Pali, >> >>> > > >> >>> > > Can you take a look at this bug report regarding a 4.2 regression for rfkill >> >>> > > after the introduction of the dell-rbtn driver please. >> >>> > > >> >>> > >> >>> > Hi! This looks strange. Driver dell_rbnt is just receiver of BIOS/ACPI >> >>> > events. It receive hotkey or slide switch event and translate it into >> >>> > either linux input keypress or rfkill block event. But dell_rbnt driver >> >>> > itself cannot set or change wireless rfkill or airplane mode. >> >>> > >> >>> > So my opinion is that BIOS/ACPI could send such event, dell_rbnt then >> >>> > propagate it into userspace and some application process it and do >> >>> > something... >> >>> > >> >>> >> >>> CCing Gabriele, owner of XPS machine too. Have you seen similar problems >> >>> with dell_rbtn as described in above bug report? >> > >> > I'll look into this ASAP. I haven't been using dell_rbtn not to disable >> > the hardware switch, but I didn't notice anything strange the last time >> > I tested it. >> >> I went back to see the old thread about dell-rbtn and apparently I was >> aware of this problem [1]. So yes, I confirm the bug. >> >> We are assuming that RBTN receives notifications only when a button >> function keys are pressed, but this is true only for some laptops, while >> others, such as my XPS13, send a notification also on resume [2]. >> This makes things a bit more complicated. >> >> CCed Alex since he might be interested in this. >> >> [1] https://marc.info/?l=linux-kernel&m=141927583032180 >> [2] https://marc.info/?l=linux-kernel&m=141941243829713 >> > > Am I correct in my understanding that there is no EC state associated with the > RFKILL for the TOGGLE type? As far as I know, yes. > Is there any point in sending the event upon resume? If not, perhaps we could > set a flag on suspend and then ignore the event on resume and then clear the > flag. This would have to be only for the affected latops though, which is > certainly not ideal. The problem is that we don't know which are the affected laptops. I suspect they are those that support both the methods to disable radio devices (software and hardware), i.e. those with a working ARBT method, such as mine. So this solution wouldn't really work properly, unless we define some time constraints, which makes the solution even worse. I'll see if I can find a batter way to deal with this problem, dell-laptop can detect the presence of an hardware switch. > -- > Darren Hart > Intel Open Source Technology Center -- 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
