Hi Arron, >>> Make Bluetooth 3.0 HS feature configurable >>> >>> Signed-off-by: Arron Wang <arron.wang@xxxxxxxxx> >>> --- >>> net/bluetooth/Kconfig | 5 + >>> net/bluetooth/Makefile | 3 +- >>> net/bluetooth/a2mp.h | 19 +++ >>> net/bluetooth/amp.h | 11 ++ >>> net/bluetooth/hci_event.c | 260 +----------------------------------- >>> net/bluetooth/hci_event_a2mp.c | 283 >> ++++++++++++++++++++++++++++++++++++++++ >>> net/bluetooth/hci_event_a2mp.h | 91 +++++++++++++ >>> 7 files changed, 412 insertions(+), 260 deletions(-) create mode >>> 100644 net/bluetooth/hci_event_a2mp.c create mode 100644 >>> net/bluetooth/hci_event_a2mp.h >> >> I don’t think this is the solution here. I think A2MP support should be self >> contained and utilises the synchronous HCI command framework we have in place >> and also use in mgmt. > > Yes, create a separate file for hci a2mp event maybe not suitable, but there are many hci ops/events for different Bluetooth controller BREDR/AMP/LE, add the macro to separate them in one file may not easy to maintain, can we move these AMP releated hci ops/event function to file amp.c? unless it has some complicated state machine impact, using the hci_request infrastructure should be preferred compared to go through callback handlers in hci_event.c. So first of all it needs to be investigated which of the A2MP HCI functions can be turned into using hci_request. 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
