Re: Error setting UUIDs discovery filter on big endian systems

[Matt <mwtaylor@xxxxxxxxx>]

On 06/03/2019 11:10, Luiz Augusto von Dentz wrote:
> Looks like the kernel is indeed assuming the length is in LE:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git/tree/net/bluetooth/mgmt.c#n3958

Thanks for pointing me to this line, removing the __le16_to_cpu() does 
seem to fix the UUIDs filter scanning on my big endian hardware, I'm not 
sure why it is needed, perhaps removing it would break LE hardware or 
some other case but I would imagine __le16_to_cpu() would do nothing in 
the LE case anyway. I have made this patch to my kernel (4.9) that seems 
to be all is needed for me to fix the issue (no changes to bluez):

diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index ba24f61..507d996 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -3599,7 +3599,7 @@ static int start_service_discovery(struct sock 
*sk, struct hci_dev *hdev,
         goto failed;
     }

-    uuid_count = __le16_to_cpu(cp->uuid_count);
+    uuid_count = cp->uuid_count;
     if (uuid_count > max_uuid_count) {
         BT_ERR("service_discovery: too big uuid_count value %u",
                uuid_count);