2010/10/28 Arnd Bergmann <arnd@arndb.de>:> On Friday 22 October 2010, Par-Gunnar Hjalmdahl wrote:>>> >>> > So - NAK this for the moment, it needs to be split cleanly into ldisc>> > (thing which speaks the protocol and eg sees "speed change required" and>> > acts on it) and device (thing which knows about the hardware).>>>> OK. We will try to figure out a new design.>> I'm not too happy about putting the ldisc part in Bluetooth though>> since it is only partly Bluetooth, it is also GPS and FM. Better could>> maybe be under char/?>> After getting a better idea of what the base mfd driver does, my impression> is now that you should not register a second N_HCI line discipline at all,> but instead extend the existing line discipline with this number.>> I'm not sure what happens if you need two modules that try to register> the same ldisc number, but I imagine it is not good.>> Shouldn't you instead be using the drivers/bluetooth/hci_{ldisc,h4} code?>> Arnd>

We also need the ldisc code to handle events from FM and GPS and sincethat is chip specific we cannot add that to the generic hci_ldisccode.I agree that we might run into problems if two drivers try to registerthe same line discipline. It might then be better to introduce a newline discipline then even though that could cause other problems. I donot know if it is possible to add a condition in Kconfig otherwise sothe CG2900 ldisc cannot be active while the "normal" ldisc driver isselected.