Hi Marcel, On Mon, Nov 21, 2011, Marcel Holtmann wrote: > > Some 1.2 controllers will fail the HCI_Read_Local_Commands HCI command > > even though (according to the specification) they should support it. > > Since this HCI command is part of the controller init sequence > > controllers broken in this manner would be unusable. Since not having > > the list of supported commands is not critical for these controllers it > > is better to just ignore failures in this case (additionally, this is > > also how older kernels used to behave). > > > > Signed-off-by: Johan Hedberg <johan.hedberg@xxxxxxxxx> > > --- > > net/bluetooth/hci_core.c | 7 +++++++ > > 1 files changed, 7 insertions(+), 0 deletions(-) > > > > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c > > index 9218888..1719257 100644 > > --- a/net/bluetooth/hci_core.c > > +++ b/net/bluetooth/hci_core.c > > @@ -106,6 +106,13 @@ void hci_req_complete(struct hci_dev *hdev, __u16 cmd, int result) > > if (test_bit(HCI_INIT, &hdev->flags) && hdev->init_last_cmd != cmd) > > return; > > > > + /* Some 1.2 controllers report failure for HCI_Read_Local_Commands > > + * even though they should support it. Since it's not a critical > > + * issue not to have a proper result from them just ignore a > > + * failure status */ > > + if (cmd == HCI_OP_READ_LOCAL_COMMANDS && result != 0) > > + result = 0; > > + > > this is pretty ugly handling. Can't we come up with something better? I just sent a second attempt at both patches. They accomplish the same thing but since we now do the handling inside the cmd_status switch statement the code becomes less hackish (at least in my opinion). Johan -- 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
