From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marcel Holtmann <marcel@holtmann.org>
Date: Wed, 01 Jul 2009 15:03:36 +0000
Subject: RE: [PATCH] Explicitly disable BT radio using rfkill interface on
Message-Id: <1246460616.12994.151.camel@localhost.localdomain>
List-Id: <linux-hotplug.vger.kernel.org>
References: <4A4A8B6D.3060509@dell.com>
In-Reply-To: <4A4A8B6D.3060509@dell.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: linux-hotplug@vger.kernel.org

Hi Mario,

> > what are you trying to solve here. And why do you need to disable a
> > Bluetooth radio on suspend? Are you trying to hack around a bug?
> 
> The problem is that a reset-resume is being ran on the BT radio device
> as well as the two virtual HID devices.  So the OS thinks that the BT
> radio device is still there after resuming from S3, but it isn't as the
> hardware is then in a different state after S3.
> 
> The initial solution I proposed was in the dell_laptop kernel module to
> run turn off/on explicitly using the rfkill interface that dell_laptop
> creates, but that not a good solution so Alan proposed adding something
> to userspace to run when the BT radio disappears but that the rest of
> the virtual HID devices are still there.

you know that we re-wrote RFKILL completely. You can kill a Bluetooth
device from within the kernel. And this looks like a hardkill of the
Bluetooth interface.

The only think that you can't do is send input events around to trigger
RFKILL. That is broken and will be removed.

Regards

Marcel