Hi Bing, >>> + cmd = (struct btmrvl_cmd *)skb->data; >>> + cmd->ocf_ogf = >>> + cpu_to_le16(hci_opcode_pack(OGF, BT_CMD_LOAD_CONFIG_DATA)); >>> + cmd->length = BT_CMD_DATA_SIZE; >>> + cmd->data[0] = 0x00; >>> + cmd->data[1] = 0x00; >>> + cmd->data[2] = 0x00; >>> + cmd->data[3] = BT_CMD_DATA_SIZE - 4; >> >> why not use __hci_cmd_sync() here. It is designed to be used from ->setup() where it is guaranteed >> that the HCI request lock is held. And it is guaranteed that ->setup() is executed in a workqueue. > > 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? 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. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
