From: Ike Panhc <ike.pan@canonical.com>
To: "Keng-Yü Lin" <kengyu@canonical.com>
Cc: Matthew Garrett <mjg@redhat.com>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org, vanhoof@canonical.com,
kent.lin@canonical.com, sylee@canonical.com
Subject: Re: [PATCH 2/2] ideapad-laptop: Handle the App-controlled RF event
Date: Tue, 05 Jul 2011 15:26:08 +0800 [thread overview]
Message-ID: <4E12BC90.2030702@canonical.com> (raw)
In-Reply-To: <BANLkTimXyoC74XhZSG7jOngYdrx7yZ7nDg@mail.gmail.com>
On 06/30/2011 06:34 PM, Keng-Yü Lin wrote:
> On Wed, Jun 29, 2011 at 2:56 PM, Ike Panhc <ike.pan@canonical.com> wrote:
>> On 06/28/2011 09:35 PM, Keng-Yu Lin wrote:
>>> Notification with VPC2 bit 5 set is generated when the wireless
>>> hotkey is pressed. BIOS fires this to notify a Windows
>>> application to handle the RF switch.
>>>
>>> On Linux, there is no such application. This patch implements
>>> a toggle for all RF devices through accessing the EC I/O ports.
>>>
>>> Without the explicit EC commands, the wifi LED is always on.
>>>
>>> Signed-off-by: Keng-Yu Lin <kengyu@canonical.com>
>>> ---
>>> drivers/platform/x86/ideapad-laptop.c | 6 +++++-
>>> 1 files changed, 5 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/platform/x86/ideapad-laptop.c b/drivers/platform/x86/ideapad-laptop.c
>>> index 820f013..5e1e971 100644
>>> --- a/drivers/platform/x86/ideapad-laptop.c
>>> +++ b/drivers/platform/x86/ideapad-laptop.c
>>> @@ -461,7 +461,11 @@ static void ideapad_acpi_notify(struct acpi_device *adevice, u32 event)
>>> if (test_bit(vpc_bit, &vpc1)) {
>>> if (vpc_bit == 9)
>>> ideapad_sync_rfk_state(adevice);
>>> - else if (vpc_bit == 4)
>>> + else if (vpc_bit == 13) {
>>> + read_ec_data(handle, 0x23, &vpc2);
>>> + write_ec_cmd(handle, 0x24, !vpc2);
>>> + ideapad_sync_rfk_state(adevice);
>>> + } else if (vpc_bit == 4)
>>> read_ec_data(handle, 0x12, &vpc2);
>>> else if (vpc_bit == 1) {
>>> } else
>>
>> I think its better to implement the changes in ideapad_sync_rfk_state() because we have
>> read switch status there. It is not necessary to read the same data twice in an event.
>>
>>
>
> Current ideapad_sync_rfk_state() code does not really toggle the
> hardware swtich (I mean to write_ec_cmd with 0x24 command). It just
> assumes that the BIOS or EC is responsible for the wifi switch-on/-off
> and reports the state via rfkill_set_hw_state().
>
> In my case, without explicit sending the 0x24 command to turn off the
> radio device, the wifi LED is always on.
>
> Though it might not be true or applicable on ideapads, in my last
> experience on Dell laptops that to switch off the RF radio in the
> driver while the hardware claims to control it can cause some mess-up.
>
> So to be safe I prefer not to move the toggle code in ideapad_sync_rfk_state().
>
> Thanks,
> -kengyu
>
Look twice and I do not think this patch is acceptable.
vpc_bit 13 is soft block key event (Fn+F5) and read_ec_data from 0x23 is
hardware switch status. This patch will mask the key report of inputdev
and to force update switch status in EC (0x24) is not a reasonable solution.
next prev parent reply other threads:[~2011-07-05 7:26 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-28 13:35 [PATCH 1/2] ideapad-laptop: Ignore an unused VPC notification Keng-Yu Lin
2011-06-28 13:35 ` [PATCH 2/2] ideapad-laptop: Handle the App-controlled RF event Keng-Yu Lin
2011-06-29 13:56 ` Ike Panhc
2011-06-30 10:34 ` Keng-Yü Lin
2011-07-05 7:26 ` Ike Panhc [this message]
2011-07-05 11:42 ` Keng-Yü Lin
2011-07-07 15:11 ` Matthew Garrett
2011-07-08 9:52 ` Joey Lee
2011-06-29 14:26 ` [PATCH 1/2] ideapad-laptop: Ignore an unused VPC notification Ike Panhc
2011-06-30 10:17 ` Keng-Yü Lin
2011-07-07 15:10 ` Matthew Garrett
2011-07-11 7:29 ` Keng-Yü Lin
2011-07-11 15:50 ` Matthew Garrett
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E12BC90.2030702@canonical.com \
--to=ike.pan@canonical.com \
--cc=kengyu@canonical.com \
--cc=kent.lin@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=platform-driver-x86@vger.kernel.org \
--cc=sylee@canonical.com \
--cc=vanhoof@canonical.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox