Hi Mat, > > First draft patches applied to my previous EFS patches. Please comment. > > > > Adds support for extended window size option (EWS) and extended control > > field. Code partly based on Atheros patches sent a year ago and Qualcomm > > code git://codeaurora.org/kernel/msm.git. > > > > To decode EWS option and extended control field please apply patch to hcidump > > which I sent to linux-bluetooth. > > > > Andrei Emeltchenko (5): > > Bluetooth: extended window size option support > > Bluetooth: l2cap extended control field support > > Bluetooth: EWS: support extended seq numbers > > Bluetooth: remove magic numbers in l2cap > > Bluetooth: prevent unneeded fragmentation in l2cap > > > > include/net/bluetooth/l2cap.h | 304 ++++++++++++++++++++++---- > > net/bluetooth/l2cap_core.c | 481 +++++++++++++++++++++++++---------------- > > net/bluetooth/l2cap_sock.c | 11 +- > > 3 files changed, 562 insertions(+), 234 deletions(-) > > > > -- > > 1.7.4.1 > > Extended window size is next on my list to upstream. As you probably > noticed, the git://codeaurora.org/kernel/msm.git code has a slightly > different approach to handling the two control field types. The > fields are handled in a struct that's part of the bt_cb control block, > and only read/written in wire format when the frame is first received > or about to be sent. Are there any issues with this method (other > than the fact that I haven't upstreamed it yet)? Some of the > subsequent L2CAP state machine changes depend on this. in general using bt_cb is fine, but it depends a little bit on the details. The space of the skb cb is limited. So we need to be cautious here. We are also currently making bt_cb global for all protocols. Maybe one way is to have l2cap_cb for this. We need to see what makes more sense and what is more efficient. > Please let me know if there are specific features from the > git://codeaurora.org/kernel/msm.git code base that you would like to > prioritize for upstreaming - there's a lot to do to bring in those > L2CAP and AMP changes, and I'll have more time to devote to it in > mid-September. I think we can gain a lot by reviewing each other's > patches and coordinating our efforts. Maybe just for reference, you should post a set of patches to the mailing list so they are archived and seen by others. Digging into a generic msm.git tree is not really efficient. 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
