| Message ID | 1309194071-7295-2-git-send-email-kengyu@canonical.com |
|---|---|
| State | New |
| Headers | show |
On 06/27/2011 06:01 PM, Keng-Yu Lin wrote: > This reverts commit a3d77411e8b2ad661958c1fbee65beb476ec6d70, > > as it causes a mess in the wireless rfkill status on some models. > It is probably a bad idea to toggle the rfkill for all dell models > without the respect to the claim that it is hardware-controlled. > > BugLink: http://bugs.launchpad.net/bugs/775281 > > Signed-off-by: Keng-Yu Lin<kengyu@canonical.com> > --- > drivers/platform/x86/dell-laptop.c | 24 ++---------------------- > 1 files changed, 2 insertions(+), 22 deletions(-) > > diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c > index ad24ef3..34657f9 100644 > --- a/drivers/platform/x86/dell-laptop.c > +++ b/drivers/platform/x86/dell-laptop.c > @@ -290,12 +290,9 @@ static int dell_rfkill_set(void *data, bool blocked) > dell_send_request(buffer, 17, 11); > > /* If the hardware switch controls this radio, and the hardware > - switch is disabled, don't allow changing the software state. > - If the hardware switch is reported as not supported, always > - fire the SMI to toggle the killswitch. */ > + switch is disabled, don't allow changing the software state */ > if ((hwswitch_state& BIT(hwswitch_bit))&& > - !(buffer->output[1]& BIT(16))&& > - (buffer->output[1]& BIT(0))) { > + !(buffer->output[1]& BIT(16))) { > ret = -EINVAL; > goto out; > } > @@ -401,23 +398,6 @@ static const struct file_operations dell_debugfs_fops = { > > static void dell_update_rfkill(struct work_struct *ignored) > { > - int status; > - > - get_buffer(); > - dell_send_request(buffer, 17, 11); > - status = buffer->output[1]; > - release_buffer(); > - > - /* if hardware rfkill is not supported, set it explicitly */ > - if (!(status& BIT(0))) { > - if (wifi_rfkill) > - dell_rfkill_set((void *)1, !((status& BIT(17))>> 17)); > - if (bluetooth_rfkill) > - dell_rfkill_set((void *)2, !((status& BIT(18))>> 18)); > - if (wwan_rfkill) > - dell_rfkill_set((void *)3, !((status& BIT(19))>> 19)); > - } > - > if (wifi_rfkill) > dell_rfkill_query(wifi_rfkill, (void *)1); > if (bluetooth_rfkill) Acked-by: Tim Gardner <tim.gardner@canonical.com>
On Mon, 2011-06-27 at 18:01 +0100, Keng-Yu Lin wrote: > This reverts commit a3d77411e8b2ad661958c1fbee65beb476ec6d70, > > as it causes a mess in the wireless rfkill status on some models. > It is probably a bad idea to toggle the rfkill for all dell models > without the respect to the claim that it is hardware-controlled. > > BugLink: http://bugs.launchpad.net/bugs/775281 > > Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> As this appears to cause a widespread regression for multiple dell models, it makes sense to revert. Will a new patch be sent to fix the original issue on the Dell Inspiron 1018? eg some sort of model specific quirk? Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> > --- > drivers/platform/x86/dell-laptop.c | 24 ++---------------------- > 1 files changed, 2 insertions(+), 22 deletions(-) > > diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c > index ad24ef3..34657f9 100644 > --- a/drivers/platform/x86/dell-laptop.c > +++ b/drivers/platform/x86/dell-laptop.c > @@ -290,12 +290,9 @@ static int dell_rfkill_set(void *data, bool blocked) > dell_send_request(buffer, 17, 11); > > /* If the hardware switch controls this radio, and the hardware > - switch is disabled, don't allow changing the software state. > - If the hardware switch is reported as not supported, always > - fire the SMI to toggle the killswitch. */ > + switch is disabled, don't allow changing the software state */ > if ((hwswitch_state & BIT(hwswitch_bit)) && > - !(buffer->output[1] & BIT(16)) && > - (buffer->output[1] & BIT(0))) { > + !(buffer->output[1] & BIT(16))) { > ret = -EINVAL; > goto out; > } > @@ -401,23 +398,6 @@ static const struct file_operations dell_debugfs_fops = { > > static void dell_update_rfkill(struct work_struct *ignored) > { > - int status; > - > - get_buffer(); > - dell_send_request(buffer, 17, 11); > - status = buffer->output[1]; > - release_buffer(); > - > - /* if hardware rfkill is not supported, set it explicitly */ > - if (!(status & BIT(0))) { > - if (wifi_rfkill) > - dell_rfkill_set((void *)1, !((status & BIT(17)) >> 17)); > - if (bluetooth_rfkill) > - dell_rfkill_set((void *)2, !((status & BIT(18)) >> 18)); > - if (wwan_rfkill) > - dell_rfkill_set((void *)3, !((status & BIT(19)) >> 19)); > - } > - > if (wifi_rfkill) > dell_rfkill_query(wifi_rfkill, (void *)1); > if (bluetooth_rfkill) > -- > 1.7.4.1 > >
On Wed, Jun 29, 2011 at 3:50 PM, Leann Ogasawara <leann.ogasawara@canonical.com> wrote: > On Mon, 2011-06-27 at 18:01 +0100, Keng-Yu Lin wrote: >> This reverts commit a3d77411e8b2ad661958c1fbee65beb476ec6d70, >> >> as it causes a mess in the wireless rfkill status on some models. >> It is probably a bad idea to toggle the rfkill for all dell models >> without the respect to the claim that it is hardware-controlled. >> >> BugLink: http://bugs.launchpad.net/bugs/775281 >> >> Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> > > As this appears to cause a widespread regression for multiple dell > models, it makes sense to revert. Will a new patch be sent to fix the > original issue on the Dell Inspiron 1018? eg some sort of model > specific quirk? > > Acked-by: Leann Ogasawara <leann.ogasawara@canonical.com> Yeah, this is a nice suggestion. I can work on adding the quirk support in dell-laptop.c and quirk Inspiron 1018 there. think also a good idea to wait until my revert patch really merged upstream. Thanks, -kengyu
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c index ad24ef3..34657f9 100644 --- a/drivers/platform/x86/dell-laptop.c +++ b/drivers/platform/x86/dell-laptop.c @@ -290,12 +290,9 @@ static int dell_rfkill_set(void *data, bool blocked) dell_send_request(buffer, 17, 11); /* If the hardware switch controls this radio, and the hardware - switch is disabled, don't allow changing the software state. - If the hardware switch is reported as not supported, always - fire the SMI to toggle the killswitch. */ + switch is disabled, don't allow changing the software state */ if ((hwswitch_state & BIT(hwswitch_bit)) && - !(buffer->output[1] & BIT(16)) && - (buffer->output[1] & BIT(0))) { + !(buffer->output[1] & BIT(16))) { ret = -EINVAL; goto out; } @@ -401,23 +398,6 @@ static const struct file_operations dell_debugfs_fops = { static void dell_update_rfkill(struct work_struct *ignored) { - int status; - - get_buffer(); - dell_send_request(buffer, 17, 11); - status = buffer->output[1]; - release_buffer(); - - /* if hardware rfkill is not supported, set it explicitly */ - if (!(status & BIT(0))) { - if (wifi_rfkill) - dell_rfkill_set((void *)1, !((status & BIT(17)) >> 17)); - if (bluetooth_rfkill) - dell_rfkill_set((void *)2, !((status & BIT(18)) >> 18)); - if (wwan_rfkill) - dell_rfkill_set((void *)3, !((status & BIT(19)) >> 19)); - } - if (wifi_rfkill) dell_rfkill_query(wifi_rfkill, (void *)1); if (bluetooth_rfkill)
This reverts commit a3d77411e8b2ad661958c1fbee65beb476ec6d70, as it causes a mess in the wireless rfkill status on some models. It is probably a bad idea to toggle the rfkill for all dell models without the respect to the claim that it is hardware-controlled. BugLink: http://bugs.launchpad.net/bugs/775281 Signed-off-by: Keng-Yu Lin <kengyu@canonical.com> --- drivers/platform/x86/dell-laptop.c | 24 ++---------------------- 1 files changed, 2 insertions(+), 22 deletions(-)