[PATCH] bluetooth: opcode field of sent commands is little endian.

[Marcel Holtmann]

Hi Michel,

> > > Fixes built-in Bluetooth not working on Apple PowerBooks, regression from
> > > commit 75fb0e324daa48ec458fb5c2960eb07b80cfad9d ('Bluetooth: Fix init sequence
> > > for some CSR based controllers').
> > > 
> > > Cc: stable at vger.kernel.org [v3.4]
> > > Signed-off-by: Michel Dänzer <michel at daenzer.net>
> > > ---
> > >  net/bluetooth/hci_core.c |    2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > > index d6dc44c..e039e3d 100644
> > > --- a/net/bluetooth/hci_core.c
> > > +++ b/net/bluetooth/hci_core.c
> > > @@ -92,7 +92,7 @@ void hci_req_complete(struct hci_dev *hdev, __u16 cmd, int result)
> > >  		 * command.
> > >  		 */
> > >  
> > > -		if (cmd != HCI_OP_RESET || sent->opcode == HCI_OP_RESET)
> > > +		if (cmd != HCI_OP_RESET || sent->opcode == cpu_to_le16(HCI_OP_RESET))
> > >  			return;
> > 
> > actually you could use __constant_cpu_to_le16() here.
> 
> Yes, but I checked and that's not used anywhere in the bluetooth code
> yet, so I thought I'd stay consistent for now.

not sure what code you are looking at, but I count 18 occurrences and we
have been fixing the ones we missed initially.

> > That said, this got actually fixed differently upstream. So I prefer if
> > that patch gets merged into stable and not this one.
> > 
> > commit 1036b89042df96e71c0cb941be212f8053ecccc0
> > Author: Andrei Emeltchenko <andrei.emeltchenko at intel.com>
> > Date:   Mon Mar 12 15:59:33 2012 +0200
> > 
> >     Bluetooth: Fix opcode access in hci_complete
> 
> Fine with me, though FWIW that not only doesn't use
> __constant_cpu_to_le16() but actually swaps the non-constant value.

Don't see what point you are trying to make here. Swapping the value
from the actual command structure is always fine with me.

> Also, it would have been nice if that fix was promoted to stable, so I
> wouldn't have had to spend a good part of the weekend bisecting...

Thinks like this happen. However after you bisected the issue you could
have just checked what is in Linus' or bluetooth-next tree. Since the
first thing I did is go through bluetooth-next and check if we have not
fixed that yet.

Regards

Marcel