[Lucid SRU] UBUNTU: SAUCE: dell-laptop: fire SMI when toggling hardware killswitch (revised)

Chase Douglas chase.douglas at canonical.com
Thu Jun 10 12:27:24 UTC 2010


On Thu, 2010-06-10 at 08:45 +0200, Stefan Bader wrote:
> Ok I saw Leann and Mario discussing what seems to the upstream replacement for
> this (so things get handled by the wmi driver). Which Mario reported to be
> working. You tested on hw that requires the change and on hw that does not
> (which I would describe with a little more detail in the testcase section of the
> justification in the bug report).
> So this would be acceptable in the revised version.

Just to be clear, the discussion between Leann and Mario was over a
different issue that is independent of this change.

That means we still need a fix for upstream, and since Maverick is based
on upstream we'll need it there too.

> 
> On 06/10/2010 08:37 AM, Keng-Yu Lin wrote:
> > Revised: wrap the long line
> > 
> > SRU Justification:
> > 
> > Impact:
> > A type of Dell Inspiron Mini does not turn off bluetooth physically when
> > pressing F2 (rfkill hotkey).
> > 
> > Fix:
> > Current kernel code expects hardware to handle the hard-rfkill switching
> > spontaneously and only notify rfkill subsystem with the status change.
> > This patch makes kernel to explicitly fire a SMI to switch on/off
> > rfkill devices if BIOS reports that the hardware switch is not supported.
> > 
> > This patch depends on the following sauce patch in lucid kernel so is not going upstream:
> >         UBUNTU: SAUCE: dell-laptop: Store the HW switch status internally rather than requerying every time
> > 
> > Testcase:
> > I tested the patch on a Dell Mini 10. It works smoothly.
> > 
> > --
> > From 59c4dae1334a279fc917ffb26a74ae4339ed8d65 Mon Sep 17 00:00:00 2001
> > From: Keng-Yu Lin <keng-yu.lin at canonical.com>
> > Date: Thu, 10 Jun 2010 11:14:11 +0800
> > Subject: [PATCH] UBUNTU: SAUCE: dell-laptop: fire SMI when toggling hardware killswitch
> > 
> > When BIOS reports hardware switch is not supported, it does not turn on/off all
> > devices spontaneously. So it is neccessary to fire an SMI to switch the rfkill
> > status explicitly when toggling the hardware killswitch.
> > 
> > BugLink: http://bugs.launchpad.net/bugs/590607
> > 
> > Signed-off-by: Keng-Yu Lin <keng-yu.lin at canonical.com>
> 
> Acked-by: Stefan Bader <stefan.bader at canonical.com>
> 
> > ---
> >  drivers/platform/x86/dell-laptop.c |    5 ++++-
> >  1 files changed, 4 insertions(+), 1 deletions(-)
> > 
> > diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell-laptop.c
> > index 15d96a0..a224f49 100644
> > --- a/drivers/platform/x86/dell-laptop.c
> > +++ b/drivers/platform/x86/dell-laptop.c
> > @@ -29,6 +29,7 @@
> >  #define WLAN_SWITCH_MASK 0
> >  #define BT_SWITCH_MASK 1
> >  #define WWAN_SWITCH_MASK 2
> > +#define HW_SWITCH_SUPPORT 3
> >  #define HW_SWITCH_MASK 16
> >  
> >  /* This structure will be modified by the firmware when we enter
> > @@ -240,7 +241,8 @@ static int dell_rfkill_set(void *data, bool blocked)
> >  	int disable = blocked ? 1 : 0;
> >  	unsigned long radio = (unsigned long)data;
> >  
> > -	if (!(hw_switch_status & BIT(radio-1)) || !(hw_switch_status & BIT(HW_SWITCH_MASK))) {
> > +	if (!(hw_switch_status & BIT(radio-1)) || !(hw_switch_status & BIT(HW_SWITCH_MASK)) || \
> > +			!(hw_switch_status & BIT(HW_SWITCH_SUPPORT))) {
> >  		memset(&buffer, 0, sizeof(struct calling_interface_buffer));
> >  		buffer.input[0] = (1 | (radio<<8) | (disable << 16));
> >  		dell_send_request(&buffer, 17, 11);
> > @@ -258,6 +260,7 @@ static void dell_rfkill_query(struct rfkill *rfkill, void *data)
> >  	dell_send_request(&buffer, 17, 11);
> >  	status = buffer.output[1];
> >  
> > +	hw_switch_status |= (status & BIT(0)) << BIT(HW_SWITCH_SUPPORT);
> >  	hw_switch_status |= (status & BIT(HW_SWITCH_MASK)) ^ BIT(HW_SWITCH_MASK);
> >  
> >  	/* HW switch control not supported
> 
> 






More information about the kernel-team mailing list