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@xxxxxxxxxxxxxxx [v3.4]
> > > > Signed-off-by: Michel Dänzer <michel@xxxxxxxxxxx>
> > > > ---
> > > > 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@xxxxxxxxx>
> > > 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
--
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
