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

[Michel Dänzer]

On Mon, 2012-06-25 at 00:22 -0700, Marcel Holtmann wrote: 
> 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.

Okay, good then. As you probably noticed from the rest of my posts, I
only checked up to 3.4.


> > > 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.

The point is that the result of swapping a constant value is just
another constant value, whereas the fix in mainline swaps a value from
memory. Not a big deal.


> > 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.

You're probably right. It just didn't occur to me that someone would
have fixed this but not forwarded the fix to stable, because I generally
do that. :}


Will you submit the fix to stable, or should I?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer