Hi Brian,
> hidraw didn't exist when Bluetooth code was adapted to use the HID
> subsystem.
> Now that it does exist, hidp is responsible for disconnecting it.
> Without
> doing this, old hidraw devices stick around forever.
>
> Signed-off-by: Brian Rogers <brian@xxxxxxxx>
> ---
> net/bluetooth/hidp/core.c | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
> index a9f7afb..5def2db 100644
> --- a/net/bluetooth/hidp/core.c
> +++ b/net/bluetooth/hidp/core.c
> @@ -40,6 +40,7 @@
>
> #include <linux/input.h>
> #include <linux/hid.h>
> +#include <linux/hidraw.h>
>
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> @@ -574,6 +575,8 @@ static int hidp_session(void *arg)
> if (session->hid) {
> if (session->hid->claimed & HID_CLAIMED_INPUT)
> hidinput_disconnect(session->hid);
> + if (session->hid->claimed & HID_CONNECT_HIDRAW)
> + hidraw_disconnect(session->hid);
> hid_destroy_device(session->hid);
> }
patch looks good. However I don't understand why the HID core can't do
that for us. This seems wrong for both cases.
Jiri, why does the HID core register input device and HIDRAW device for
us, but not disconnect it?
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
