| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Apr 2015 14:06:27 +0800 From: Alex Hung <alex.hung@...onical.com> To: Pali Rohár <pali.rohar@...il.com> Cc: Gabriele Mazzotta <gabriele.mzt@...il.com>, Matthew Garrett <mjg59@...f.ucam.org>, Darren Hart <dvhart@...radead.org>, "platform-driver-x86@...r.kernel.org" <platform-driver-x86@...r.kernel.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH v2 1/3] platform: x86: dell-rbtn: Dell Airplane Mode Switch driver Method ABRT is to be used by driver to disable BIOS handling of radio button. So the changes in behaviours observed by Gabriele is expected. I have seen other systems behave the same way. I do also see firmware only sends Notify(RBTN, 0x80) and no hard block whether ABRT(1) is called or not. Thus keycode are the only option on those machines. The idea to have an option (kernel parameter) for calling ABRT is great. I can help verify on more machines. Is Gabriele's patch above a final version that I should test? On Thu, Apr 30, 2015 at 2:59 AM, Pali Rohár <pali.rohar@...il.com> wrote: > On Wednesday 29 April 2015 20:41:38 Gabriele Mazzotta wrote: >> On Wednesday 29 April 2015 20:16:06 Pali Rohár wrote: >> > On Wednesday 29 April 2015 20:11:38 Gabriele Mazzotta wrote: >> > > On Wednesday 29 April 2015 20:00:18 Pali Rohár wrote: >> > > > On Wednesday 29 April 2015 19:54:43 Gabriele Mazzotta >> > > > wrote: >> > > > > On Wednesday 29 April 2015 18:28:40 Pali Rohár wrote: >> > > > > > On Wednesday 29 April 2015 15:57:58 Gabriele Mazzotta >> > > > > > wrote: >> > > > > > > On Wednesday 29 April 2015 15:08:40 Pali Rohár >> > > > > > > wrote: >> > > > > > > > On Wednesday 29 April 2015 12:30:32 Gabriele >> > > > > > > > Mazzotta wrote: >> > > > > > > > > On Wednesday 29 April 2015 11:51:04 Pali Rohár >> > > > > > > > > wrote: >> > > > > > > > > > This is an ACPI driver for Dell laptops >> > > > > > > > > > which receive HW switch events. It exports >> > > > > > > > > > rfkill device dell-rbtn which provide >> > > > > > > > > > correct hard rfkill state. >> > > > > > > > > > >> > > > > > > > > > Alex Hung added code for supporting Dell >> > > > > > > > > > laptops which have toggle button instead HW >> > > > > > > > > > slider switch. On these laptops toggle >> > > > > > > > > > button event is reported by new input >> > > > > > > > > > device (instead rfkill) as they do not have >> > > > > > > > > > hw radio switch. >> > > > > > > > > > >> > > > > > > > > > It looks like those are two different >> > > > > > > > > > functions (rfkill, input device), but Dell >> > > > > > > > > > BIOS exports them via same ACPI device and >> > > > > > > > > > uses same ACPI functions. So code is in one >> > > > > > > > > > kernel driver. >> > > > > > > > > >> > > > > > > > > I made a patch some time ago that I've just >> > > > > > > > > adapted. It allows to prefer RBTN_SLIDER over >> > > > > > > > > RBTN_TOGGLE. The main reason why I'd like to >> > > > > > > > > have the hardware switch is that the BIOS >> > > > > > > > > doesn't alter the soft state of the devices. >> > > > > > > > > This comes in handy when the function key >> > > > > > > > > controls multiple radio devices. >> > > > > > > > >> > > > > > > > Now I'm thinking... is't this bug in wifi kernel >> > > > > > > > driver (which exports phy rfkill)? Or problem >> > > > > > > > somewhere else (userspace or kernel)? >> > > > > > > >> > > > > > > What is the presumed bug you are referring to? The >> > > > > > > fact that the soft state doesn't change? >> > > > > > >> > > > > > Can you remind me whats the problem on your laptop? >> > > > > >> > > > > CRBT returns 0 (so RBTN_TOGGLE), but by default my >> > > > > laptop acts as if it returned 2 or 3, so we have to >> > > > > call ARBT. >> > > > > >> > > > > As said before, there's no way to know when a platform >> > > > > whose CRBT method returns 0 or 1 also has the >> > > > > hardware switch, so to be sure that all the platforms >> > > > > have working function keys, some of them (such as >> > > > > mine) have to give up on the hardware switch. >> > > > >> > > > Ok, and what happens when you load this v2 version? What >> > > > stopped working on your laptop? >> > > > >> > > > Alex, can you help? Code for toggle laptop version is >> > > > originally yours. >> > > >> > > When I press the Fn key, a _Qxx EC method is executed. The >> > > code path of this method depends on a variable set by >> > > ARBT. >> > > >> > > When you call ARBT with 1 as argument, the variable is set >> > > to 1 and the _Qxx method does nothing but sending a >> > > notification (0x80) to RBTN whenever the function key is >> > > pressed. >> > > >> > > When you call ARBT with 0 as argument, the variable is set >> > > to 0 and the _Qxx method both sends 0x80 to RBTN _and_ >> > > toggle the state of the radio devices whenever the >> > > function key is pressed. >> > > >> > > So in the end nothing _really_ breaks. >> > >> > So in linux kernel is missing code for toggling state of >> > radio devices? And you can do that only by ACPI when ARBT >> > is called with 0, right? >> >> Yes. >> >> With Alex's code the kernel sends keypresses to userspace and >> userspace takes care of toggling the state of radio devices. > > Alex, can you ask Dell for documentation how to enable/disable > radio devices? Because when ARBT is set to 1, then system must > take care of it but, linux does not support it yet... > > -- > Pali Rohár > pali.rohar@...il.com -- Cheers, Alex Hung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists