1. 31 7月, 2014 14 次提交
    • V
      6lowpan: remove unused macros · 267ca9fe
      Varka Bhadram 提交于
      This patch removes the unused macros.
      Signed-off-by: NVarka Bhadram <varkab@cdac.in>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      267ca9fe
    • M
      6lowpan: iphc: Fix parenthesis alignments which off-by-one · 3fa71fe0
      Marcel Holtmann 提交于
      CHECK: Alignment should match open parenthesis
      +	if (((hdr->flow_lbl[0] & 0x0F) == 0) &&
      +	     (hdr->flow_lbl[1] == 0) && (hdr->flow_lbl[2] == 0)) {
      
      CHECK: Alignment should match open parenthesis
      +		if ((hdr->priority == 0) &&
      +		   ((hdr->flow_lbl[0] & 0xF0) == 0)) {
      
      CHECK: Alignment should match open parenthesis
      +		if ((hdr->priority == 0) &&
      +		   ((hdr->flow_lbl[0] & 0xF0) == 0)) {
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      3fa71fe0
    • M
      6lowpan: iphc: Fix missing braces for if statement · 9ab9bb00
      Marcel Holtmann 提交于
      CHECK: braces {} should be used on all arms of this statement
      +	if ((iphc0 & 0x03) != LOWPAN_IPHC_TTL_I)
      [...]
      +	else {
      [...]
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      9ab9bb00
    • M
      6lowpan: iphc: Fix missing blank line after variable declarations · 26fff593
      Marcel Holtmann 提交于
      WARNING: Missing a blank line after declarations
      +		struct sk_buff *new;
      +		if (uncompress_udp_header(skb, &uh))
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      26fff593
    • M
      6lowpan: iphc: Fix issues with alignment matching open parenthesis · 7fc4cfda
      Marcel Holtmann 提交于
      This patch fixes all the issues with alignment matching of open
      parenthesis found by checkpatch.pl and makes them follow the
      network coding style now.
      
      CHECK: Alignment should match open parenthesis
      +static int uncompress_addr(struct sk_buff *skb,
      +				struct in6_addr *ipaddr, const u8 address_mode,
      
      CHECK: Alignment should match open parenthesis
      +static int uncompress_context_based_src_addr(struct sk_buff *skb,
      +						struct in6_addr *ipaddr,
      
      CHECK: Alignment should match open parenthesis
      +static int skb_deliver(struct sk_buff *skb, struct ipv6hdr *hdr,
      +		struct net_device *dev, skb_delivery_cb deliver_skb)
      
      CHECK: Alignment should match open parenthesis
      +	new = skb_copy_expand(skb, sizeof(struct ipv6hdr), skb_tailroom(skb),
      +								GFP_ATOMIC);
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__, "raw skb data dump before receiving",
      +			new->data, new->len);
      
      CHECK: Alignment should match open parenthesis
      +lowpan_uncompress_multicast_daddr(struct sk_buff *skb,
      +		struct in6_addr *ipaddr,
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_inline(NULL, "Reconstructed ipv6 multicast addr is",
      +				ipaddr->s6_addr, 16);
      
      CHECK: Alignment should match open parenthesis
      +int lowpan_process_data(struct sk_buff *skb, struct net_device *dev,
      +		const u8 *saddr, const u8 saddr_type, const u8 saddr_len,
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__, "raw skb data dump uncompressed",
      +				skb->data, skb->len);
      
      CHECK: Alignment should match open parenthesis
      +		err = uncompress_addr(skb, &hdr.saddr, tmp, saddr,
      +					saddr_type, saddr_len);
      
      CHECK: Alignment should match open parenthesis
      +		err = uncompress_addr(skb, &hdr.daddr, tmp, daddr,
      +					daddr_type, daddr_len);
      
      CHECK: Alignment should match open parenthesis
      +		pr_debug("dest: stateless compression mode %d dest %pI6c\n",
      +			tmp, &hdr.daddr);
      
      CHECK: Alignment should match open parenthesis
      +		raw_dump_table(__func__, "raw UDP header dump",
      +				      (u8 *)&uh, sizeof(uh));
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__, "raw header dump", (u8 *)&hdr,
      +							sizeof(hdr));
      
      CHECK: Alignment should match open parenthesis
      +int lowpan_header_compress(struct sk_buff *skb, struct net_device *dev,
      +			unsigned short type, const void *_daddr,
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__, "raw skb network header dump",
      +		skb_network_header(skb), sizeof(struct ipv6hdr));
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__,
      +			"sending raw skb network uncompressed packet",
      
      CHECK: Alignment should match open parenthesis
      +	if (((hdr->flow_lbl[0] & 0x0F) == 0) &&
      +	     (hdr->flow_lbl[1] == 0) && (hdr->flow_lbl[2] == 0)) {
      
      WARNING: quoted string split across lines
      +			pr_debug("dest address unicast link-local %pI6c "
      +				"iphc1 0x%02x\n", &hdr->daddr, iphc1);
      
      CHECK: Alignment should match open parenthesis
      +	raw_dump_table(__func__, "raw skb data dump compressed",
      +				skb->data, skb->len);
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      7fc4cfda
    • M
      6lowpan: iphc: Fix block comments to match networking style · 89f53490
      Marcel Holtmann 提交于
      This patch fixes all the block comment issues found by checkpatch.pl and
      makes them match the network style now.
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +/*
      + * Based on patches from Jon Smirl <jonsmirl@gmail.com>
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +/*
      + * Uncompress address function for source and
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +/*
      + * Uncompress address function for source context
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +		/*
      +		 * UDP lenght needs to be infered from the lower layers
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * Traffic Class and FLow Label carried in-line
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * Traffic class carried in-line
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * Flow Label carried in-line
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +		/*
      +		 * replace the compressed UDP head by the uncompressed UDP
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * As we copy some bit-length fields, in the IPHC encoding bytes,
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * Traffic class, flow label
      
      WARNING: networking block comments don't use an empty /* line, use /* Comment...
      +	/*
      +	 * Hop limit
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      89f53490
    • A
      6lowpan: remove unused LOWPAN_FRAG_SIZE define · 00494244
      Alexander Aring 提交于
      This define is unused since commit
      96cb3eb7 ("6lowpan: fix fragmentation on
      sending side"). It is a worst case scenario for payload calculation.
      Since commit 96cb3eb7 we calculation the
      payload to use the optimal size.
      
      This define is also necessary for ieee802154 6lowpan only and the file
      include/net/6lowpan.h should contain generic 6lowpan things only.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      00494244
    • A
      6lowpan: iphc: remove check on null · b2e3a479
      Alexander Aring 提交于
      This memory is placed on stack and can't be null so remove the check on
      null.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      b2e3a479
    • A
      6lowpan: iphc: use ipv6 api to check address scope · 556a5bfc
      Alexander Aring 提交于
      This patch removes the own implementation to check of link-layer,
      broadcast and any address type and use the IPv6 api for that.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      556a5bfc
    • A
      6lowpan: iphc: cleanup use of lowpan_push_hc_data · 85c71240
      Alexander Aring 提交于
      This patch uses the lowpan_push_hc_data functions in several places
      where we can use it. The lowpan_push_hc_data was introduced in some
      previous patches.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      85c71240
    • A
      6lowpan: iphc: cleanup use of lowpan_fetch_skb · 4ebc960f
      Alexander Aring 提交于
      We introduced the lowpan_fetch_skb function in some previous patches for
      6lowpan to have a generic fetch function. This patch drops the old
      function and use the generic lowpan_fetch_skb one.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4ebc960f
    • A
      8ec1d9be
    • A
      6lowpan: iphc: rename hc06_ptr pointer to hc_ptr · 84ca5e03
      Alexander Aring 提交于
      The hc06_ptr pointer variable stands for header compression draft-06. We
      are mostly rfc complaint. This patch rename the variable to normal hc_ptr.
      Signed-off-by: NAlexander Aring <alex.aring@gmail.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      84ca5e03
    • J
      Bluetooth: Fix SMP context tracking leading to a kernel crash · 616d55be
      Johan Hedberg 提交于
      The HCI_CONN_LE_SMP_PEND flag is supposed to indicate whether we have an
      SMP context or not. If the context creation fails, or some other error
      is indicated between setting the flag and creating the context the flag
      must be cleared first.
      
      This patch ensures that smp_chan_create() clears the flag in case of
      allocation failure as well as reorders code in smp_cmd_security_req()
      that could lead to returning an error between setting the flag and
      creating the context.
      
      Without the patch the following kind of kernel crash could be observed
      (this one because of unacceptable authentication requirements in a
      Security Request):
      
      [  +0.000855] kernel BUG at net/bluetooth/smp.c:606!
      [  +0.000000] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [  +0.000000] CPU: 0 PID: 58 Comm: kworker/u5:2 Tainted: G        W     3.16.0-rc1+ #785
      [  +0.008391] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
      [  +0.000000] Workqueue: hci0 hci_rx_work
      [  +0.000000] task: f4dc8f90 ti: f4ef0000 task.ti: f4ef0000
      [  +0.000000] EIP: 0060:[<c13432b6>] EFLAGS: 00010246 CPU: 0
      [  +0.000000] EIP is at smp_chan_destroy+0x1e/0x145
      [  +0.000709] EAX: f46db870 EBX: 00000000 ECX: 00000000 EDX: 00000005
      [  +0.000000] ESI: f46db870 EDI: f46db870 EBP: f4ef1dc0 ESP: f4ef1db0
      [  +0.000000]  DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
      [  +0.000000] CR0: 8005003b CR2: b666b0b0 CR3: 00022000 CR4: 00000690
      [  +0.000000] DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      [  +0.000000] DR6: fffe0ff0 DR7: 00000400
      [  +0.000000] Stack:
      [  +0.000000]  00000005 f17b7840 f46db870 f4ef1dd4 f4ef1de4 c1343441 c134342e 00000000
      [  +0.000000]  c1343441 00000005 00000002 00000000 f17b7840 f4ef1e38 c134452a 00002aae
      [  +0.000000]  01ef1e00 00002aae f46bd980 f46db870 00000039 ffffffff 00000007 f4ef1e34
      [  +0.000000] Call Trace:
      [  +0.000000]  [<c1343441>] smp_failure+0x64/0x6c
      [  +0.000000]  [<c134342e>] ? smp_failure+0x51/0x6c
      [  +0.000000]  [<c1343441>] ? smp_failure+0x64/0x6c
      [  +0.000000]  [<c134452a>] smp_sig_channel+0xad6/0xafc
      [  +0.000000]  [<c1053b61>] ? vprintk_emit+0x343/0x366
      [  +0.000000]  [<c133f34e>] l2cap_recv_frame+0x1337/0x1ac4
      [  +0.000000]  [<c133f34e>] ? l2cap_recv_frame+0x1337/0x1ac4
      [  +0.000000]  [<c1172307>] ? __dynamic_pr_debug+0x3e/0x40
      [  +0.000000]  [<c11702a1>] ? debug_smp_processor_id+0x12/0x14
      [  +0.000000]  [<c1340bc9>] l2cap_recv_acldata+0xe8/0x239
      [  +0.000000]  [<c1340bc9>] ? l2cap_recv_acldata+0xe8/0x239
      [  +0.000000]  [<c1169931>] ? __const_udelay+0x1a/0x1c
      [  +0.000000]  [<c131f120>] hci_rx_work+0x1a1/0x286
      [  +0.000000]  [<c137244e>] ? mutex_unlock+0x8/0xa
      [  +0.000000]  [<c131f120>] ? hci_rx_work+0x1a1/0x286
      [  +0.000000]  [<c1038fe5>] process_one_work+0x128/0x1df
      [  +0.000000]  [<c1038fe5>] ? process_one_work+0x128/0x1df
      [  +0.000000]  [<c10392df>] worker_thread+0x222/0x2de
      [  +0.000000]  [<c10390bd>] ? process_scheduled_works+0x21/0x21
      [  +0.000000]  [<c103d34c>] kthread+0x82/0x87
      [  +0.000000]  [<c1040000>] ? create_new_namespaces+0x90/0x105
      [  +0.000000]  [<c13738e1>] ret_from_kernel_thread+0x21/0x30
      [  +0.000000]  [<c103d2ca>] ? __kthread_parkme+0x50/0x50
      [  +0.000000] Code: 65 f4 89 f0 5b 5e 5f 5d 8d 67 f8 5f c3 57 8d 7c 24 08 83 e4 f8 ff 77 fc 55 89 e5 57 89 c7 56 53 52 8b 98 e0 00 00 00 85 db 75 02 <0f> 0b 8b b3 80 00 00 00 8b 00 c1 ee 03 83 e6 01 89 f2 e8 ef 09
      [  +0.000000] EIP: [<c13432b6>] smp_chan_destroy+0x1e/0x145 SS:ESP 0068:f4ef1db0
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      616d55be
  2. 29 7月, 2014 11 次提交
  3. 28 7月, 2014 2 次提交
  4. 27 7月, 2014 3 次提交
  5. 26 7月, 2014 2 次提交
    • M
      Bluetooth: Fix white list handling with resolvable private addresses · 66d8e837
      Marcel Holtmann 提交于
      Devices using resolvable private addresses are required to provide
      an identity resolving key. These devices can not be found using
      the current controller white list support. This means if the kernel
      knows about any devices with an identity resolving key, the white
      list filtering must be disabled.
      
      However so far the kernel kept identity resolving keys around even
      for devices that are not using resolvable private addresses. The
      notification to userspace clearly hints to not store the key and
      so it is best to just remove the key from the kernel as well at
      that point.
      
      With this it easy now to detect when using the white list is
      possible or when kernel side resolving of addresses is required.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      66d8e837
    • M
      Bluetooth: Add support for using controller white list filtering · 8540f6c0
      Marcel Holtmann 提交于
      The Bluetooth controller can use a white list filter when scanning
      to avoid waking up the host for devices that are of no interest.
      
      Devices marked as reporting, direct connection (incoming) or general
      connection are now added to the controller white list. The update of
      the white list happens just before enabling passive scanning.
      
      In case the white list is full and can not hold all devices, the
      white list is not used and the filter policy set to accept all
      advertisements.
      
      Using the white list for scanning allows for power saving with
      controllers that do not handle the duplicate filtering correctly.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      8540f6c0
  6. 25 7月, 2014 5 次提交
    • J
      9a244409
    • J
      ath10k: handle attention flags correctly when using A-MSDU · 0ccb7a34
      Janusz Dziedzic 提交于
      In case of A-MSDU RX we should check attention flags
      correctly to be sure we report correct FCS status for
      A-MSDU subframes. Without a patch we could report A-MSDU
      subframes with wrong FCS as a correct to the stack, next
      get a lot of DUP ACK TCP packets. Finally TP drop is seen
      and this drop depends on FCS errors ratio for A-MSDU frame.
      
      Example test case when TP drop is seen:
      - ath10k configured as an AP
      - used ath10k station
      - forced A-MSDU (7 frames) on STA
      - other traffic on channel (often FCS errors)
      - monitor iface added on AP
      - TCP STA -> AP traffic (iperf)
      
      a) Iperf logs for case without the patch:
      
      echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU
      [ ID] Interval       Transfer     Bandwidth
      [  3]  0.0- 5.0 sec  56.6 MBytes  95.0 Mbits/sec
      [  3]  5.0-10.0 sec  60.4 MBytes   101 Mbits/sec
      [  3] 10.0-15.0 sec  60.2 MBytes   101 Mbits/sec
      [  3] 15.0-20.0 sec  60.2 MBytes   101 Mbits/sec
      [  3] 20.0-25.0 sec  63.8 MBytes   107 Mbits/sec
      [  3] 25.0-30.0 sec  64.9 MBytes   109 Mbits/sec
      
      echo "7 64" > htt_max_amsdu_ampdu  // set 7 A-MSDU subframes
      [  3] 30.0-35.0 sec  40.0 MBytes  67.1 Mbits/sec
      [  3] 35.0-40.0 sec  35.9 MBytes  60.2 Mbits/sec
      [  3] 40.0-45.0 sec  36.9 MBytes  61.9 Mbits/sec
      [  3] 45.0-50.0 sec  37.9 MBytes  63.5 Mbits/sec
      [  3] 50.0-55.0 sec  34.5 MBytes  57.9 Mbits/sec
      [  3] 55.0-60.0 sec  25.4 MBytes  42.6 Mbits/sec
      [  3] 60.0-65.0 sec  48.2 MBytes  81.0 Mbits/sec
      [  3] 65.0-70.0 sec  28.8 MBytes  48.2 Mbits/sec
      [  3] 70.0-75.0 sec  29.2 MBytes  49.1 Mbits/sec
      [  3] 75.0-80.0 sec  22.9 MBytes  38.4 Mbits/sec
      [  3] 80.0-85.0 sec  26.4 MBytes  44.2 Mbits/sec
      [  3] 85.0-90.0 sec  31.5 MBytes  52.8 Mbits/sec
      
      b) Iperf logs for case with patch:
      
      echo "1 64" > htt_max_amsdu_ampdu // disable A-MSDU
      [  3] local 192.168.12.2 port 57512 connected with 192.168.12.1 port 5001
      [ ID] Interval       Transfer     Bandwidth
      [  3]  0.0- 5.0 sec  60.8 MBytes   102 Mbits/sec
      [  3]  5.0-10.0 sec  62.2 MBytes   104 Mbits/sec
      [  3] 10.0-15.0 sec  60.9 MBytes   102 Mbits/sec
      
      echo "7 64" > htt_max_amsdu_ampdu  // set 7 A-MSDU subframes
      [  3] 15.0-20.0 sec  68.1 MBytes   114 Mbits/sec
      [  3] 20.0-25.0 sec  80.5 MBytes   135 Mbits/sec
      [  3] 25.0-30.0 sec  83.0 MBytes   139 Mbits/sec
      [  3] 30.0-35.0 sec  79.1 MBytes   133 Mbits/sec
      [  3] 35.0-40.0 sec  77.1 MBytes   129 Mbits/sec
      [  3] 40.0-45.0 sec  77.4 MBytes   130 Mbits/sec
      Reported-by: NDenton Gentry <denton.gentry@gmail.com>
      Signed-off-by: NJanusz Dziedzic <janusz.dziedzic@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      0ccb7a34
    • M
      ath10k: don't advertise IBSS iftype for 10.x · cf850d1d
      Michal Kazior 提交于
      The 10.x firmware does not support IBSS mode at
      all. It can't beacon and it crashes when trying to
      scan.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      cf850d1d
    • M
      ath10k: fix Rx aggregation reordering · aa5b4fbc
      Michal Kazior 提交于
      Firmware doesn't perform Rx reordering so it is
      left to the host driver to do that.
      
      Use mac80211 to perform reordering instead of
      re-inventing the wheel.
      
      This fixes TCP throughput issues in some
      environments.
      Reported-by: NDenton Gentry <denton.gentry@gmail.com>
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NKalle Valo <kvalo@qca.qualcomm.com>
      aa5b4fbc
    • K
      30d88ce3
  7. 24 7月, 2014 3 次提交
    • M
      Bluetooth: Fix issue with ADV_IND reports and auto-connection handling · 4b9e7e75
      Marcel Holtmann 提交于
      When adding remote devices to the kernel using the Add Device management
      command, these devices are explicitly allowed to connect. This kind of
      incoming connections are possible even when the controller itself is
      not connectable.
      
      For BR/EDR this distinction is pretty simple since there is only one
      type of incoming connections. With LE this is not that simple anymore
      since there are ADV_IND and ADV_DIRECT_IND advertising events.
      
      The ADV_DIRECT_IND advertising events are send for incoming (slave
      initiated) connections only. And this is the only thing the kernel
      should allow when adding devices using action 0x01. This meaning
      of incoming connections is coming from BR/EDR and needs to be
      mapped to LE the same way.
      
      Supporting the auto-connection of devices using ADV_IND advertising
      events is an important feature as well. However it does not map to
      incoming connections. So introduce a new action 0x02 that allows
      the kernel to connect to devices using ADV_DIRECT_IND and in addition
      ADV_IND advertising reports.
      
      This difference is represented by the new HCI_AUTO_CONN_DIRECT value
      for only connecting to ADV_DIRECT_IND. For connection to ADV_IND and
      ADV_DIRECT_IND the old value HCI_AUTO_CONN_ALWAYS is used.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      4b9e7e75
    • M
      Bluetooth: Ignore ADV_DIRECT_IND attempts from unknown devices · cd4d5671
      Marcel Holtmann 提交于
      Unconditionally connecting to devices sending ADV_DIRECT_IND when
      the controller is in CONNECTABLE mode is a feature that is not
      fully working. The background scanning trigger for this has been
      removed, but the statement allowing it to happen in case some
      other part triggers is still present. So remove that code part
      as well to avoid unwanted connections.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      cd4d5671
    • M
      Bluetooth: Get MWS transport configuration of the controller · f4fe73ed
      Marcel Holtmann 提交于
      If the Bluetooth controller supports Get MWS Transport Layer
      Configuration command, then issue it during initialization.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      f4fe73ed