Re: [PATCH] bluetooth: ask for MWS transport config only if controller supports 4.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hey Marcel,

so it is actually not that this chip does not understand this command, it is that it is being stupid.

It lead me to the assumption that the chip does something pretty wired here as I didn't found this command in the 4.0 spec and when saying "I am supporting 4.0" I would assume it doesn't mix any of the new commands from newer spec versions in. However didn't saw that it was added in the addendum ...

< HCI Command: Get MWS Transport Layer.. (0x05|0x000c) plen 0
HCI Event: Command Complete (0x0e) plen 5
       Get MWS Transport Layer Configuration (0x05|0x000c) ncmd 1
         Status: Unknown Connection Identifier (0x02)
         Number of transports: 0
         Baud rate list: 0 entries

The command is properly supported. I just don't know why it needs to return with an error. And especially error 0x02 which makes no sense in this case since the command is not even taking a connection handle in the first place.

< HCI Command: Read Local Version Info.. (0x04|0x0001) plen 0
HCI Event: Command Complete (0x0e) plen 12
       Read Local Version Information (0x04|0x0001) ncmd 1
         Status: Success (0x00)
         HCI version: Bluetooth 4.0 (0x06) - Revision 0 (0x0000)
         LMP version: Bluetooth 4.0 (0x06) - Subversion 0 (0x0000)
         Manufacturer: MediaTek, Inc. (70)
< HCI Command: Read BD ADDR (0x04|0x0009) plen 0
HCI Event: Command Complete (0x0e) plen 10
       Read BD ADDR (0x04|0x0009) ncmd 1
         Status: Success (0x00)
         Address: 38:BC:1A:1F:7E:96 (Meizu technology co.,ltd)

So it seems that MediaTek needs to work a bit on their HCI command support. Which module is this anyway? Who builds it and where can it be found? Is this USB or UART? If it is USB, please provide /sys/kernel/debug/usb/devices entry for this one.

As far as I know it is the MT6630QP chip and its connected over UART.

I have the feeling we are missing some sort of firmware update here that would allow to fix this controller.

Generally I would say this is the way to go too but that isn't really an option in this case. So either we come up with a general solution by adding a quirk for this or I patch this just on our kernel.

And I forgot to note that MWS actually was a CSA. So it is valid for Bluetooth 4.0 controllers. It is just that Bluetooth 4.1 included all previous CSA.

I see. That is why I didn't found it in the 4.0 spec. Thanks for the hint!

regards,
Simon
--
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



[Index of Archives]     [Bluez Devel]     [Linux Wireless Networking]     [Linux Wireless Personal Area Networking]     [Linux ATH6KL]     [Linux USB Devel]     [Linux Media Drivers]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux