Hi Marcel, > > The reason of not using __hci_cmd_sync() is that we are sending vendor specific command here > (MRVL_VENDOR_PKT). The __hci_cmd_sync seems handle HCI_COMMAND_PKT only. > > Please let us know if you have any suggestion to solve this problem. > > what is a MRVL_VENDOR_PKT actually? It's defined as 0xfe in our driver. The firmware doesn't understand 0xff (HCI_VENDOR_PKT). > > If you guys are not using standard HCI command/event for vendor operation, then this obviously does > not fit. However a similar model might make sense instead of manually building packets all the time. We can extend __hci_cmd_sync() function with a new parameter 'type'. This way we can pass HCI_VENDOR_PKT into __hci_cmd_sync(), while other drivers will pass in HCI_COMMAND_PKT. Our driver will make HCI_VENDOR_PKT -> MRVL_VENDOR_PKT conversion before downloading the frame to firmware. And the MRVL_VENDOR_PKT frame from firmware will be replaced with HCI_VENDOR_PKT while uploading the frame to stack. Please let us know if this approach works for you or not. Thanks, Bing -- 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
