Hi, sorry for the delay... On 12/22/2016 12:38 AM, Wong, Joshua Weng Onn wrote: ... > > I have discussed this with my technical lead and that he mentioned that we will not be able to pursue to bring it to Linux mainline and also not able to backport the drivers due to resource limitation. We have pending tasks/projects that are upcoming. > ok. > Just curious, can we know the estimated timeline that it will take for an inexperienced person in Linux kernel development to complete this task? > it would take so long until everything is fine and every reviewer has no comments on it what it could be made better... But one issue at my patch series is that bluetooth L2CAP code has not asynchronous Transmit function, which is not that what it's expected by netdev xmit callback... So I queued it into a workqueue -> some people would say it's a bug, some people would say "it's works for now". I think it's also very difficult to add such behaviour because l2cap_chan mutex need to be replaced by some different fast locking mechanism - if linux-bluetooth really want such behaviour... Anyway, queueing into a workqueue is "okay" for me, because the way to do it right would be complicated. :-/ Also there exists still the question about which L2 address should be really be used and when we need to set it. - Alex -- To unsubscribe from this list: send the line "unsubscribe linux-wpan" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
