Re: [PATCH] bluetooth: opcode field of sent commands is little endian.
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: sta...@vger.kernel.org [v3.4]
> Signed-off-by: Michel Dänzer
> ---
> 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.
That said, this got actually fixed differently upstream. So I prefer if
that patch gets merged into stable and not this one.
commit 1036b89042df96e71c0cb941be212f8053e0
Author: Andrei Emeltchenko
Date: Mon Mar 12 15:59:33 2012 +0200
Bluetooth: Fix opcode access in hci_complete
In general patches need to get into Linus' tree first before you can
even request them for stable.
Regards
Marcel
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] bluetooth: opcode field of sent commands is little endian.
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: sta...@vger.kernel.org [v3.4]
> > > Signed-off-by: Michel Dänzer
> > > ---
> > > 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 1036b89042df96e71c0cb941be212f8053e0
> > Author: Andrei Emeltchenko
> > 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
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Hi Dave, More fallout from the premature mISDN driver merge: drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now" is that only the HFC driver or the whole mISDN stack? I know that the two old ISDN stacks where really bad on big endian, but my assumption was that we did sort this out in the end. One of the two mISDN drivers uses the deprecated virt_to_bus() interface for handling DMA addresses (that doesn't even work on many x86 systems these days) and the other mISDN driver gives the above big-endian compile time error. In short, this driver was not ready for merging at all. I am not defending it and agree that this driver should have had at least one test run in linux-next. However mISDN is a whole ISDN stack. So does mISDN has an issue too or do we only have a really broken driver. Karsten? Regards Marcel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
Hi Dave, More fallout from the premature mISDN driver merge: drivers/isdn/hardware/mISDN/hfcmulti.c:5255:2: error: #error "not running on big endian machines now" is that only the HFC driver or the whole mISDN stack? I know that the two old ISDN stacks where really bad on big endian, but my assumption was that we did sort this out in the end. Regards Marcel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
