Hi Bing, >>> 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). so it is actually out-of-channel vendor packet. >> >> 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. That will actually not work. And I also do not want to do that. The __hci_cmd_sync() is for real HCI packets. That means types 0x01 and 0x04 only. They need to adhere to the HCI flow control mechanism for commands. > 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. I think this is best kept inside the driver. However you might consider building something like __hci_cmd_sync() that is specific to your driver, but allows for a similar flow within ->setup(). Regards Marcel -- 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
