Hi Christophe, On Tue, Jan 27, 2015 at 11:16:32PM +0100, christophe.ricard wrote: > The main reason for making an st21nfcb_hci_core is because the hci network > initialization procedure is proprietary. > It is almost using only NCI standard commands but some id's and commands > could be proprietary. That could most likely be fixed with an additional NCI hook. > I would ideally rely on the hci core framework but i run out of idea when > trying this. > However i think "exporting the relevant API for drivers to send HCI > commands/events through their NCI connections." Yes, the idea would be for the NCI core to create an hci_dev and associate it with the right nci_dev (probably when the driver requests it). Then you should be able to call into the HCI core API, even if it takes exporting some of it. > is a good idea i need to dig into. It will then needs to hci/nci hook for > the proprietary stuff. > > I have just one worry, when do you think those updates (patch 20 & 27) needs > to be ready for your 3.20 pull request ? I'm going to send a first pull request tomorrow. And a second one beginning of next week. I realize it leaves you with very little time, but I feel patch #27 is quite a bit of potentially duplicated code. What about you look at patch #20 first and I could then take all your patchset except for patches #27 and #28 ? Cheers, Samuel. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html