[Bluetooth] Track connection packet type changes

The connection packet type can be changed after the connection has been
established and thus needs to be properly tracked to ensure that the
host stack has always correct and valid information about it.

On incoming connections the Bluetooth core switches the supported packet
types to the configured list for this controller. However the usefulness
of this feature has been questioned a lot. The general consent is that
every Bluetooth host stack should enable as many packet types as the
hardware actually supports and leave the decision to the link manager
software running on the Bluetooth chip.

When running on Bluetooth 2.0 or later hardware, don't change the packet
type for incoming connections anymore. This hardware likely supports
Enhanced Data Rate and thus leave it completely up to the link manager
to pick the best packet type.

Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

1 files changed, 9 insertions, 0 deletions

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index a8a9eb6af966..f1dc174abc2a 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -137,6 +137,8 @@ enum {
 #define ESCO_EV4	0x0010
 #define ESCO_EV5	0x0020
 
+#define SCO_ESCO_MASK  (ESCO_HV1 | ESCO_HV2 | ESCO_HV3)
+
 /* ACL flags */
 #define ACL_CONT		0x01
 #define ACL_START		0x02
@@ -696,6 +698,13 @@ struct hci_ev_clock_offset {
 	__le16   clock_offset;
 } __attribute__ ((packed));
 
+#define HCI_EV_PKT_TYPE_CHANGE		0x1d
+struct hci_ev_pkt_type_change {
+	__u8     status;
+	__le16   handle;
+	__le16   pkt_type;
+} __attribute__ ((packed));
+
 #define HCI_EV_PSCAN_REP_MODE		0x20
 struct hci_ev_pscan_rep_mode {
 	bdaddr_t bdaddr;