From: kbuild test robot <lkp@intel.com>
To: spoorthix.k@intel.com
Cc: kbuild-all@01.org, linux-bluetooth@vger.kernel.org,
linux-bluetooth-owner@vger.kernel.org, bharat.b.panda@intel.com
Subject: Re: [PATCH] Add support to use resolving list
Date: Tue, 13 Aug 2019 02:15:19 +0800 [thread overview]
Message-ID: <201908130224.91RHn2ZD%lkp@intel.com> (raw)
In-Reply-To: <1565606947-28164-1-git-send-email-spoorthix.k@intel.com>
[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]
Hi,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.3-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/spoorthix-k-intel-com/Add-support-to-use-resolving-list/20190812-233201
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-10) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
net//bluetooth/hci_request.c: In function 'hci_req_add_le_passive_scan':
>> net//bluetooth/hci_request.c:1015:3: warning: 'ext_filter_policy' may be used uninitialized in this function [-Wmaybe-uninitialized]
hci_req_start_scan(req, LE_SCAN_PASSIVE, hdev->le_scan_interval,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hdev->le_scan_window, own_addr_type,
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ext_filter_policy);
~~~~~~~~~~~~~~~~~~
vim +/ext_filter_policy +1015 net//bluetooth/hci_request.c
966
967 void hci_req_add_le_passive_scan(struct hci_request *req)
968 {
969 struct hci_dev *hdev = req->hdev;
970 u8 own_addr_type;
971 u8 filter_policy;
972 u8 ext_filter_policy;
973
974 /* Set require_privacy to false since no SCAN_REQ are send
975 * during passive scanning. Not using an non-resolvable address
976 * here is important so that peer devices using direct
977 * advertising with our address will be correctly reported
978 * by the controller.
979 */
980 if (hci_update_random_address(req, false, scan_use_rpa(hdev),
981 &own_addr_type))
982 return;
983
984 /* Adding or removing entries from the white list must
985 * happen before enabling scanning. The controller does
986 * not allow white list modification while scanning.
987 */
988 filter_policy = update_white_list(req);
989
990 if (hdev->le_features[0] & HCI_LE_LL_PRIVACY) {
991 ext_filter_policy = update_resolve_list(req);
992 if (!ext_filter_policy) {
993 /* If resolve list can not be used then check if
994 * whitelist can be used and set filter policy
995 * accordingly.
996 */
997 ext_filter_policy = filter_policy;
998 }
999 }
1000 /* When the controller is using random resolvable addresses and
1001 * with that having LE privacy enabled, then controllers with
1002 * Extended Scanner Filter Policies support can now enable support
1003 * for handling directed advertising.
1004 *
1005 * So instead of using filter polices 0x00 (no whitelist)
1006 * and 0x01 (whitelist enabled) use the new filter policies
1007 * 0x02 (no whitelist) and 0x03 (whitelist enabled).
1008 */
1009 if (hci_dev_test_flag(hdev, HCI_PRIVACY) &&
1010 (hdev->le_features[0] & HCI_LE_EXT_SCAN_POLICY) &&
1011 (!(hdev->le_features[0] & HCI_LE_LL_PRIVACY)))
1012 filter_policy |= 0x02;
1013
1014 if (hdev->le_features[0] & HCI_LE_LL_PRIVACY)
> 1015 hci_req_start_scan(req, LE_SCAN_PASSIVE, hdev->le_scan_interval,
1016 hdev->le_scan_window, own_addr_type,
1017 ext_filter_policy);
1018 else
1019 hci_req_start_scan(req, LE_SCAN_PASSIVE, hdev->le_scan_interval,
1020 hdev->le_scan_window, own_addr_type,
1021 filter_policy);
1022 }
1023
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 69475 bytes --]
next prev parent reply other threads:[~2019-08-12 18:15 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-12 10:49 [PATCH] Add support to use resolving list spoorthix.k
2019-08-12 18:15 ` kbuild test robot [this message]
2019-08-14 8:18 spoorthix.k
2019-08-15 6:56 ` Marcel Holtmann
2019-08-29 7:22 [PATCH] Add Support to use Resolving List spoorthix.k
2019-08-29 19:11 ` kbuild test robot
2019-08-30 8:13 [PATCH] Add Support to use Resolving list spoorthix.k
2019-09-05 15:43 ` Marcel Holtmann
2019-09-18 10:36 [PATCH] Add support " spoorthix.k
2019-09-27 7:07 ` Marcel Holtmann
2019-09-27 7:14 ` Johan Hedberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201908130224.91RHn2ZD%lkp@intel.com \
--to=lkp@intel.com \
--cc=bharat.b.panda@intel.com \
--cc=kbuild-all@01.org \
--cc=linux-bluetooth-owner@vger.kernel.org \
--cc=linux-bluetooth@vger.kernel.org \
--cc=spoorthix.k@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).