Par, > Well, from what I can see LL is an extension of the H4, basically it > adds sleep mode handling in a vendor specific way to the normal H4 > protocol. So it is also based on the hci_h4 just as our file is. But > our file has basically nothing in common with what has been for the LL > file. We don't support any of the LL sleep commands for example. > So if I would make a driver for a combo chip supporting LL, I would > either modify the existing hci_ll.c or I would make a new file based > on hci_ll.c. There is not much you could really reuse from our new > file. Basically it would be the handling of any common channels, so if > you would for example have the same specification of FM and GPS you > could maybe save around 20 lines of common code, but you would > probably have to add a lot of more code just to keep the solution > generic. Right, but this gives me the hard time seeing how your implementation is applicable to other multi-functional chips with similar functionality. > One major difference is also that hci_ll never changes baud rate or > other settings. I assume that is done from hciattach during startup > instead. But we cannot run with that since we have to shut down the > chip when no user is connected in order to save power. This means that > we have to add vendor specific commands in order to for example set > baud rate. And then you run into these vendor specific problems. If > there would be a standardized specification on how to set baud rate > and how to put chip in sleep I assume things could be solved > differently, but that is not the case. Again, there are at least TI and Broadcom chips that support HCI_LL and if they were to use your implementation of the core, they would have had to add 2 more implementations of the corresponding line discipline driver. > As a quick answer to your question: that would depend on the > difference between the different controllers, I guess. But CG2900 > doesn't support the LL protocol so it is not an issue for that. Right, but if you are only aiming cg2000, why would you create a framework for that? I initially thought your solution was generic enough to handle other "many-in-one" Bluetooth chips but I'm completely unsure about that now. Thanks, Vitaly -- 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
