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