Hi Marcel, > > 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. I see. > > > 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(). Sure, we will consider building a function in the driver to handle this. 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
