Testing a little more, I found that on fresh boots the latest bluez.git
doesn't always work to switch dell BT adapters to HCI mode depending on
the state of the killswitch on boot. Whenever running hid2hci, the
kernel driver should attempt to be released. As long as this is done
before trying to claim, each of the scenarios is successful. The
previous dmesg errors were coming up because the order of the
usb_claim_interface and usb_detach_kernel_driver_np were reversed.
The commit message should be shortened this time too, sorry about that
before.
---
From 3e40fbd035b35613c8d1ad3f0aa11a639f487600 Mon Sep 17 00:00:00 2001
From: Mario Limonciello <[email protected]>
Date: Mon, 18 May 2009 13:07:40 -0500
Subject: [PATCH] Reinstitute usb_detach_kernel_driver_np, but in the
proper place.
The kernel might still be grab the usb device, so release it before claim.
---
tools/hid2hci.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
--
Mario Limonciello
*Dell | Linux Engineering*
[email protected]
Hi Mario,
> Testing a little more, I found that on fresh boots the latest bluez.git
> doesn't always work to switch dell BT adapters to HCI mode depending on
> the state of the killswitch on boot. Whenever running hid2hci, the
> kernel driver should attempt to be released. As long as this is done
> before trying to claim, each of the scenarios is successful. The
> previous dmesg errors were coming up because the order of the
> usb_claim_interface and usb_detach_kernel_driver_np were reversed.
the patch has been applied. However I prefer if you stop making the code
so complex that my brain hurts. I changed that now. It should really
just to "if error then bail out of the function".
Regards
Marcel