Hi Suraj, > > So first of all, lets make something perfectly clear. All Bluetooth > > drivers are _transport_ drivers. They don't need to know what they are > > transporting. And in addition you should not look into the packets that > > you are sending or receiving. The Bluetooth core does that HCI packet > > parsing. > > > > This is how I want it and how this is going to stay. Everything else is > > an insane approach and cost every single driver overhead. In addition > > the lifetime rules of SKBs become more and more complicated. That is a > > pretty bad thing. It will result in excessive memory usage and will > > cause problems. > > I understand the point that you are making. But If I am not mistaken, > HCI transport driver is the only part of the system that could be vendor > specific ( HCI ATH3K, HCI LL etc). So a vendor specific command or event > makes more sense to a transport driver than anybody else. > > Is there anyway this requirement can be sufficed without causing the > issues you have mentioned above? so you might be able to convince me if you implement something proper for handling vendor commands. The basic assumption is still that a HCI driver is a pure transport driver. However you have access to hci_dev. So if you create some functions to execute vendor commands and retrieve the results then this might be a way. The core already processes vendor commands and events. But keep in mind that there is no requirement to get a command status or command complete event for vendor commands. For example CSR doesn't send them for their vendor commands. 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
