Return-Path: Subject: Re: [RFC 06/15] Bluetooth: Background scanning Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Andre Guedes In-Reply-To: Date: Fri, 18 Oct 2013 11:26:04 -0300 Cc: linux-bluetooth@vger.kernel.org Message-Id: <92D59E31-6A7C-4D17-BC08-66DB402A9513@openbossa.org> References: <1381965485-9159-1-git-send-email-andre.guedes@openbossa.org> <1381965485-9159-7-git-send-email-andre.guedes@openbossa.org> To: Marcel Holtmann List-ID: Hi Marcel, On Oct 17, 2013, at 6:31 AM, Marcel Holtmann wrote: > Hi Andre, >=20 >> This patch adds helpers to trigger and untrigger the background >> scanning. As long as the number of triggers are greater than zero, >> we keep the background scanning running. Once the number of triggers >> reaches zero, it is stopped. >>=20 >> Signed-off-by: Andre Guedes >> --- >> include/net/bluetooth/hci_core.h | 7 ++++ >> net/bluetooth/hci_core.c | 83 = ++++++++++++++++++++++++++++++++++++++++ >> 2 files changed, 90 insertions(+) >>=20 >> diff --git a/include/net/bluetooth/hci_core.h = b/include/net/bluetooth/hci_core.h >> index 1e67da5..cb6458a 100644 >> --- a/include/net/bluetooth/hci_core.h >> +++ b/include/net/bluetooth/hci_core.h >> @@ -288,6 +288,10 @@ struct hci_dev { >> __u8 scan_rsp_data[HCI_MAX_AD_LENGTH]; >> __u8 scan_rsp_data_len; >>=20 >> + /* This counter tracks the number of background scanning = triggers >> + */ >> + atomic_t background_scan_cnt; >> + >> int (*open)(struct hci_dev *hdev); >> int (*close)(struct hci_dev *hdev); >> int (*flush)(struct hci_dev *hdev); >> @@ -1191,4 +1195,7 @@ void hci_le_start_enc(struct hci_conn *conn, = __le16 ediv, __u8 rand[8], >> #define SCO_AIRMODE_CVSD 0x0000 >> #define SCO_AIRMODE_TRANSP 0x0003 >>=20 >> +int hci_trigger_background_scan(struct hci_dev *hdev); >> +int hci_untrigger_background_scan(struct hci_dev *hdev); >> + >=20 > instead of plastering the code with all these places it might be = better to create a connection parameter hash that actually knows if it = has any connection parameters stored that need require a passive scan = now. >=20 > So instead of trigger and intriguer, the code that adds or removes the = actual data from our hash can be the trigger itself. Since it knows = better. And checking after disconnection or other cases becomes a lot = simpler since you just check the hash if you should be connecting. I'll follow this approach in v2. Regards, Andre=