Re: 057c:3800 BlueFRITZ! Bluetooth Stick broken since 2.6.something

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Marcel,

On Mon, Nov 21, 2011, Marcel Holtmann wrote:
> > > On Fri, Nov 18, 2011, Michael Schmitt wrote:
> > > > < HCI Command: Read Local Version Information (0x04|0x0001) plen 0
> > > > > HCI Event: Command Complete (0x0e) plen 12
> > > >     Read Local Version Information (0x04|0x0001) ncmd 1
> > > >     status 0x00
> > > >     HCI Version: 1.2 (0x2) HCI Revision: 0x2006
> > > >     LMP Version: 1.2 (0x2) LMP Subversion: 0x1806
> > > >     Manufacturer: AVM Berlin (31)
> > > 
> > > Ok, so this is a 1.2 adapter.
> > > 
> > > > < HCI Command: Read Local Supported Commands (0x04|0x0002) plen 0
> > > > > HCI Event: Command Status (0x0f) plen 4
> > > >     Read Local Supported Commands (0x04|0x0002) status 0x01 ncmd 1
> > > >     Error: Unknown HCI Command
> > > 
> > > This is the reason why you're getting a timeout. Since the adapter
> > > claims to support Bluetooth version 1.2 it should also support this HCI
> > > command, so from that perspective it's not conforming to the
> > 
> > Apparently we check for "Bluetooth Core Specification 1.1" 
> > 
> > Shall we change to:
> > 
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index f0fbb02..ed55b33 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -562,7 +562,7 @@ static void hci_setup(struct hci_dev *hdev)
> >  {
> >         hci_setup_event_mask(hdev);
> >  
> > -       if (hdev->lmp_ver > 1)
> > +       if (hdev->lmp_ver > 2)
> >                 hci_send_cmd(hdev, HCI_OP_READ_LOCAL_COMMANDS, 0, NULL);
> 
> 0x00 is 1.0b and 0x01 is 1.1. So you are changing the check from 1.2 to
> 2.0. The command was introduced with 1.2 actually.
> 
> The only real change that needs to be done here is to check hci_ver
> instead of lmp_ver. This command is a HCI feature and not a LMP feature
> actually.

That doesn't help much with this particular dongle though since the LMP
and HCI versions are the same. What I'd propose is the patch which I
already attached to an earlier email in this thread and then either a
quirk for this adapter or just generally ignoring the
HCI_Read_Local_Commands failure status.

Johan