Multi-advertising cycle time broken for non-default intervals. |
|||||||||||||||||||||||||||||||||
Issue descriptionCurrently when we change the advertising interval, we don't change the interval at which we switch out multi-advertisements. So, if we set the advertising interval to 100ms, instead of seeing, Adv1 <100ms> Adv2 <100ms> Adv1 <100ms> Adv2 (This would be correct behavior) instead, we see, Adv1 <100ms> Adv1 <100ms> (10-12 times, till 1.28s are over) Adv2 <100ms> Adv2 <100ms> (10-12 times, till 1.28s are over) This is incorrect. This is because when switching the advertising interval, we did not chance the advertising switch intervals in the kernel. We need this for M55.
,
Oct 13 2016
Hi Raj, the advertising interval is a global value for all advertisements as the example given in Comment#0.
Hence, we might not be able to support the following varying intervals for M55 that you mentioned in an email thread yesterday.
In case of multi-advertisement scenario, we need to make sure different
advertisement are correctly sequenced -
Adv1 @ 200ms, Adv2 @ 400 ms, Adv1 @600 ms and so on
Is this fine with you?
,
Oct 13 2016
Hi Rahul, assuming that the advertising interval is 100 ms in the correct behavior given in Comment#0, the actual intervals between two consecutive Adv1 would be 200 ms. And the actual intervals between two consecutive Adv2 would be 200 ms. Is this intended? Or should we switch between Adv1 and Adv2 every 50 ms so that the actual intervals between Adv1 (and Adv2 as well) would be 100 ms? Thanks!
,
Oct 13 2016
Hi Joseph- what I meant was, if we set a global value of 100ms as advertising frequency and if there are two registered advertisements, the behavior should be Adv1 <100ms> Adv2 <100ms> Adv1 <100ms> Adv2 <100ms> ..... If one more advertisement gets registered, the behavior should be Adv1 <100ms> Adv2 <100ms> Adv3 <100ms> Adv1 <100ms> Adv2 <100ms> Adv3 <100ms> ..... Re: comment #3, if the advertising frequency is set to 100ms and if there are two registered advertisements, it means that the interval between adv1 and adv2 is 100ms. You are correct that the time between two consecutive adv1 will be 200 ms in that case.
,
Oct 13 2016
I got it. Thank you for the detailed explanations!
,
Oct 21 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/768362c86a0e84d52cde438effa1d7721b8f300a commit 768362c86a0e84d52cde438effa1d7721b8f300a Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> [modify] https://crrev.com/768362c86a0e84d52cde438effa1d7721b8f300a/net/bluetooth/mgmt.c [modify] https://crrev.com/768362c86a0e84d52cde438effa1d7721b8f300a/net/bluetooth/hci_core.c [modify] https://crrev.com/768362c86a0e84d52cde438effa1d7721b8f300a/include/net/bluetooth/hci_core.h [modify] https://crrev.com/768362c86a0e84d52cde438effa1d7721b8f300a/net/bluetooth/hci_request.c
,
Oct 22 2016
The patch in Comment#6 needs to be cherry-picked to R55. Thanks!
,
Oct 24 2016
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/c5e55a84598e30cd7dd42ced463c8d67dbbf20f8 commit c5e55a84598e30cd7dd42ced463c8d67dbbf20f8 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/402790 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/c5e55a84598e30cd7dd42ced463c8d67dbbf20f8/net/bluetooth/mgmt.c [modify] https://crrev.com/c5e55a84598e30cd7dd42ced463c8d67dbbf20f8/net/bluetooth/hci_core.c [modify] https://crrev.com/c5e55a84598e30cd7dd42ced463c8d67dbbf20f8/include/net/bluetooth/hci_core.h [modify] https://crrev.com/c5e55a84598e30cd7dd42ced463c8d67dbbf20f8/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b836d15a1005ad965216727388877d5554233eab commit b836d15a1005ad965216727388877d5554233eab Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/402792 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/b836d15a1005ad965216727388877d5554233eab/net/bluetooth/mgmt.c [modify] https://crrev.com/b836d15a1005ad965216727388877d5554233eab/net/bluetooth/hci_core.c [modify] https://crrev.com/b836d15a1005ad965216727388877d5554233eab/include/net/bluetooth/hci_core.h [modify] https://crrev.com/b836d15a1005ad965216727388877d5554233eab/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/da0652628e1dd7fe286f2c6a31a01bad91a0a721 commit da0652628e1dd7fe286f2c6a31a01bad91a0a721 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/402793 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/da0652628e1dd7fe286f2c6a31a01bad91a0a721/net/bluetooth/mgmt.c [modify] https://crrev.com/da0652628e1dd7fe286f2c6a31a01bad91a0a721/net/bluetooth/hci_core.c [modify] https://crrev.com/da0652628e1dd7fe286f2c6a31a01bad91a0a721/include/net/bluetooth/hci_core.h [modify] https://crrev.com/da0652628e1dd7fe286f2c6a31a01bad91a0a721/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/5f25a7921c2960c93a1bf6756441e9cb80ba6c8a commit 5f25a7921c2960c93a1bf6756441e9cb80ba6c8a Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/402791 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/5f25a7921c2960c93a1bf6756441e9cb80ba6c8a/net/bluetooth/mgmt.c [modify] https://crrev.com/5f25a7921c2960c93a1bf6756441e9cb80ba6c8a/net/bluetooth/hci_core.c [modify] https://crrev.com/5f25a7921c2960c93a1bf6756441e9cb80ba6c8a/include/net/bluetooth/hci_core.h [modify] https://crrev.com/5f25a7921c2960c93a1bf6756441e9cb80ba6c8a/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b99383735752879fda03ccf9e3bad5367bfa7d62 commit b99383735752879fda03ccf9e3bad5367bfa7d62 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/402794 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/b99383735752879fda03ccf9e3bad5367bfa7d62/net/bluetooth/mgmt.c [modify] https://crrev.com/b99383735752879fda03ccf9e3bad5367bfa7d62/net/bluetooth/hci_core.c [modify] https://crrev.com/b99383735752879fda03ccf9e3bad5367bfa7d62/include/net/bluetooth/hci_core.h [modify] https://crrev.com/b99383735752879fda03ccf9e3bad5367bfa7d62/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/cfc4e390b7ff69011c03c62284688e8e1dbac97d commit cfc4e390b7ff69011c03c62284688e8e1dbac97d Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/401305 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/cfc4e390b7ff69011c03c62284688e8e1dbac97d/net/bluetooth/mgmt.c [modify] https://crrev.com/cfc4e390b7ff69011c03c62284688e8e1dbac97d/net/bluetooth/hci_core.c [modify] https://crrev.com/cfc4e390b7ff69011c03c62284688e8e1dbac97d/include/net/bluetooth/hci_core.h [modify] https://crrev.com/cfc4e390b7ff69011c03c62284688e8e1dbac97d/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/05a013c73de6f4f753813d906ece3b290534d569 commit 05a013c73de6f4f753813d906ece3b290534d569 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/401306 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/05a013c73de6f4f753813d906ece3b290534d569/net/bluetooth/mgmt.c [modify] https://crrev.com/05a013c73de6f4f753813d906ece3b290534d569/net/bluetooth/hci_core.c [modify] https://crrev.com/05a013c73de6f4f753813d906ece3b290534d569/include/net/bluetooth/hci_core.h [modify] https://crrev.com/05a013c73de6f4f753813d906ece3b290534d569/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/abf210375d2ab74bf2afbc32f5fa022564501314 commit abf210375d2ab74bf2afbc32f5fa022564501314 Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/401304 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/abf210375d2ab74bf2afbc32f5fa022564501314/net/bluetooth/mgmt.c [modify] https://crrev.com/abf210375d2ab74bf2afbc32f5fa022564501314/net/bluetooth/hci_core.c [modify] https://crrev.com/abf210375d2ab74bf2afbc32f5fa022564501314/include/net/bluetooth/hci_core.h [modify] https://crrev.com/abf210375d2ab74bf2afbc32f5fa022564501314/net/bluetooth/hci_request.c
,
Oct 26 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b7eb1cf2a490c022a5f884f4573c93b181c8360d commit b7eb1cf2a490c022a5f884f4573c93b181c8360d Author: Joseph Hwang <josephsih@chromium.org> Date: Fri Oct 14 06:34:08 2016 CHROMIUM: bluetooth: adjust advertising duration based on max interval The advertising duration determines how long an advertisement is advertised. As the default duration is 2000 ms, the controller will keep advertising the same advertisement continuously in the duration until the duration times out and next advertisement instance is scheduled. This behavior makes shorter advertising intervals useless. This patch adjusts the duration according to the max advertising interval so that multiple advertisements could be interleaved in a round-robin manner. Besides, a millisecond is used as the unit of duration instead of a second for finer resolution. BUG= chromium:655251 TEST=Run the chrome advertising test app, use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: Id436029c6a11116d09c1f01ea2bfe0e0047de015 Reviewed-on: https://chromium-review.googlesource.com/400202 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> (cherry picked from commit 768362c86a0e84d52cde438effa1d7721b8f300a) Reviewed-on: https://chromium-review.googlesource.com/401303 Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/b7eb1cf2a490c022a5f884f4573c93b181c8360d/net/bluetooth/mgmt.c [modify] https://crrev.com/b7eb1cf2a490c022a5f884f4573c93b181c8360d/net/bluetooth/hci_core.c [modify] https://crrev.com/b7eb1cf2a490c022a5f884f4573c93b181c8360d/include/net/bluetooth/hci_core.h [modify] https://crrev.com/b7eb1cf2a490c022a5f884f4573c93b181c8360d/net/bluetooth/hci_request.c
,
Oct 27 2016
The patch for fixing kernel in Comment#6 has merged into 5 kernel versions on R55. One more patch is in review for fixing its autotest. I will request to merge it when landing on ToT later. So I will remove Merge-Approved-55 for now. Thanks.
,
Oct 29 2016
Two more patches fixed the autotest have landed on ToT. https://chromium-review.googlesource.com/#/c/403571/ https://chromium-review.googlesource.com/#/c/403572/ They need to be cherry-picked to R55. Thanks!
,
Oct 29 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Oct 30 2016
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 1 2016
The two CLs mentioned in Comment#19 have landed on R55.
,
Nov 10 2016
A patch is in review to fix a bug occurring when advertising intervals are set after advertisements are registered.
,
Nov 10 2016
,
Nov 16 2016
Continued from Comment#23, the patch "CHROMIUM: bluetooth: set advertising intervals after registering advertisements" (https://chromium-review.googlesource.com/#/c/406775/) should be cherry-picked to M55 too. I plan to cherry-pick the patch to M55 as soon as it lands on ToT. Thanks!
,
Nov 16 2016
Your change meets the bar and is auto-approved for M55 (branch: 2883)
,
Nov 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2839031c3d631aae1a44c4f56cf8664ed32ad267 commit 2839031c3d631aae1a44c4f56cf8664ed32ad267 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/hci_core.c [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/include/net/bluetooth/hci_core.h [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/mgmt.c
,
Nov 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2839031c3d631aae1a44c4f56cf8664ed32ad267 commit 2839031c3d631aae1a44c4f56cf8664ed32ad267 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/hci_core.c [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/include/net/bluetooth/hci_core.h [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/mgmt.c
,
Nov 16 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/2839031c3d631aae1a44c4f56cf8664ed32ad267 commit 2839031c3d631aae1a44c4f56cf8664ed32ad267 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/hci_core.c [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/include/net/bluetooth/hci_core.h [modify] https://crrev.com/2839031c3d631aae1a44c4f56cf8664ed32ad267/net/bluetooth/mgmt.c
,
Nov 17 2016
The patch in Comment#27 has landed on kernel chromeos-3.10. I am cherry-picking it to chromeos-3.18, chromeos-3.14, chromeos-3.18, and chromeos-4.4. Once they landed on all kernel versions without problems, I will cherry-pick them to corresponding kernel versions in R55.
,
Nov 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/90f7f7d33e3e6b24c5759f1b08fc12590a77438f commit 90f7f7d33e3e6b24c5759f1b08fc12590a77438f Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/411556 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/90f7f7d33e3e6b24c5759f1b08fc12590a77438f/net/bluetooth/hci_core.c [modify] https://crrev.com/90f7f7d33e3e6b24c5759f1b08fc12590a77438f/include/net/bluetooth/hci_core.h [modify] https://crrev.com/90f7f7d33e3e6b24c5759f1b08fc12590a77438f/net/bluetooth/mgmt.c
,
Nov 18 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/827159fc46fdf7793c3cf2509ab8a166da703d65 commit 827159fc46fdf7793c3cf2509ab8a166da703d65 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/411553 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/827159fc46fdf7793c3cf2509ab8a166da703d65/net/bluetooth/hci_core.c [modify] https://crrev.com/827159fc46fdf7793c3cf2509ab8a166da703d65/include/net/bluetooth/hci_core.h [modify] https://crrev.com/827159fc46fdf7793c3cf2509ab8a166da703d65/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/6581a287a838380f1d79a3e94915bbfa025431a8 commit 6581a287a838380f1d79a3e94915bbfa025431a8 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/412564 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/6581a287a838380f1d79a3e94915bbfa025431a8/net/bluetooth/hci_core.c [modify] https://crrev.com/6581a287a838380f1d79a3e94915bbfa025431a8/include/net/bluetooth/hci_core.h [modify] https://crrev.com/6581a287a838380f1d79a3e94915bbfa025431a8/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/bd5abde08909ad1d2982a97951d6885116f6671d commit bd5abde08909ad1d2982a97951d6885116f6671d Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/412561 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/bd5abde08909ad1d2982a97951d6885116f6671d/net/bluetooth/hci_core.c [modify] https://crrev.com/bd5abde08909ad1d2982a97951d6885116f6671d/include/net/bluetooth/hci_core.h [modify] https://crrev.com/bd5abde08909ad1d2982a97951d6885116f6671d/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/b848568eca1505b46b63c5c8a4fbe13c3b2d3ff5 commit b848568eca1505b46b63c5c8a4fbe13c3b2d3ff5 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/412562 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/b848568eca1505b46b63c5c8a4fbe13c3b2d3ff5/net/bluetooth/hci_core.c [modify] https://crrev.com/b848568eca1505b46b63c5c8a4fbe13c3b2d3ff5/include/net/bluetooth/hci_core.h [modify] https://crrev.com/b848568eca1505b46b63c5c8a4fbe13c3b2d3ff5/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/78d850a4bfe28d1919f9935f25791eecb0ce8b8d commit 78d850a4bfe28d1919f9935f25791eecb0ce8b8d Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/412565 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/78d850a4bfe28d1919f9935f25791eecb0ce8b8d/net/bluetooth/hci_core.c [modify] https://crrev.com/78d850a4bfe28d1919f9935f25791eecb0ce8b8d/include/net/bluetooth/hci_core.h [modify] https://crrev.com/78d850a4bfe28d1919f9935f25791eecb0ce8b8d/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e8e0d94e9a95da320ca353870160a9ae58fe60b4 commit e8e0d94e9a95da320ca353870160a9ae58fe60b4 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/411554 Commit-Ready: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/e8e0d94e9a95da320ca353870160a9ae58fe60b4/net/bluetooth/hci_core.c [modify] https://crrev.com/e8e0d94e9a95da320ca353870160a9ae58fe60b4/include/net/bluetooth/hci_core.h [modify] https://crrev.com/e8e0d94e9a95da320ca353870160a9ae58fe60b4/net/bluetooth/mgmt.c
,
Nov 19 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/ef9a0d272a40088e3fda833a64e17afed162ab96 commit ef9a0d272a40088e3fda833a64e17afed162ab96 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/412563 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/ef9a0d272a40088e3fda833a64e17afed162ab96/net/bluetooth/hci_core.c [modify] https://crrev.com/ef9a0d272a40088e3fda833a64e17afed162ab96/include/net/bluetooth/hci_core.h [modify] https://crrev.com/ef9a0d272a40088e3fda833a64e17afed162ab96/net/bluetooth/mgmt.c
,
Nov 29 2016
This issue has been fixed by the CL in comment #29. And the patch has landed on R55.
,
Nov 29 2016
I see at least a kernel change in kernel 4.4 that's tagged with this bug and _not_ in R56. Please confirm whether you also need merges to M56, get approval, and merge them. Thanks.
,
Nov 30 2016
Hi Doug, thank you for reminding! I do need to merge the patch to the following 4 kernel branches of M56: release-R56-9000.B-chromeos-3.8 release-R56-9000.B-chromeos-3.14 release-R56-9000.B-chromeos-3.18 release-R56-9000.B-chromeos-4.4 Note that "release-R56-9000.B-chromeos-3.10" has included this patch since it was merged before branch date.
,
Nov 30 2016
Your change meets the bar and is auto-approved for M56 (branch: 2924)
,
Dec 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/0e8c6d1ab126c2184ca9f14506756b1ae94f80f9 commit 0e8c6d1ab126c2184ca9f14506756b1ae94f80f9 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/415135 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/0e8c6d1ab126c2184ca9f14506756b1ae94f80f9/net/bluetooth/hci_core.c [modify] https://crrev.com/0e8c6d1ab126c2184ca9f14506756b1ae94f80f9/include/net/bluetooth/hci_core.h [modify] https://crrev.com/0e8c6d1ab126c2184ca9f14506756b1ae94f80f9/net/bluetooth/mgmt.c
,
Dec 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/a3a774aec7ff5d66d6c05a1853221f1335b58aef commit a3a774aec7ff5d66d6c05a1853221f1335b58aef Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/415136 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/a3a774aec7ff5d66d6c05a1853221f1335b58aef/net/bluetooth/hci_core.c [modify] https://crrev.com/a3a774aec7ff5d66d6c05a1853221f1335b58aef/include/net/bluetooth/hci_core.h [modify] https://crrev.com/a3a774aec7ff5d66d6c05a1853221f1335b58aef/net/bluetooth/mgmt.c
,
Dec 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/229670578a2cbd0e6eef82c3e80bc2e982de0262 commit 229670578a2cbd0e6eef82c3e80bc2e982de0262 Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/415134 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/229670578a2cbd0e6eef82c3e80bc2e982de0262/net/bluetooth/hci_core.c [modify] https://crrev.com/229670578a2cbd0e6eef82c3e80bc2e982de0262/include/net/bluetooth/hci_core.h [modify] https://crrev.com/229670578a2cbd0e6eef82c3e80bc2e982de0262/net/bluetooth/mgmt.c
,
Dec 1 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromiumos/third_party/kernel/+/4f2f52d01d0cf062df2df35e3095a2f191f2d8af commit 4f2f52d01d0cf062df2df35e3095a2f191f2d8af Author: Joseph Hwang <josephsih@chromium.org> Date: Wed Nov 02 07:56:04 2016 CHROMIUM: bluetooth: set advertising intervals after registering advertisements There are some problems if advertising intervals are set after registrations of advertisement instances: - only 1 instance would keep advertising, and - instead of the original public address, a random address will be used. The problems are fixed by - modifying the duration of every existing advertisement instance, - only modifying the duration if the duration of an instance was NOT specified during the registration * individual_duration_flag: This adds a flag to mark the advertising instances whose advertising durations were provided during registration. The advertising durations of the instances with this flag set to true would not be modified by the dbus SetAdvertisingIntervals method. On the other hand, the advertising duration of the instances with this flag set to false would be updated with the new values specified by the dbus SetAdvertisingIntervals method. - removing the re-enabling advertising code which is unnecessary. Since a new instance will be registered with advertising intervals through the regular procedure which makes the configuration of advertising simper and robust. BUG= chromium:655251 TEST=Verify that the two chrome advertising test apps run correctly. Original App: Run the original chrome advertising test app which registers 3 advertisement instances *after* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. The new App: Run the chrome advertising test "app2" which registers 3 advertisement instances *before* setting advertising intervals. Use nRF Connect, and watch that the advertisement instances are interleaved in a round-robin manner. Change-Id: I7978e30ad582651124a8decd95808302bdce137c Reviewed-on: https://chromium-review.googlesource.com/406775 Commit-Ready: Miao-chen Chou <mcchou@chromium.org> Tested-by: Shyh-In Hwang <josephsih@chromium.org> Reviewed-by: Rahul Chaturvedi <rkc@chromium.org> Reviewed-by: Miao-chen Chou <mcchou@chromium.org> (cherry picked from commit 2839031c3d631aae1a44c4f56cf8664ed32ad267) Reviewed-on: https://chromium-review.googlesource.com/415133 Trybot-Ready: Miao-chen Chou <mcchou@chromium.org> Commit-Queue: Shyh-In Hwang <josephsih@chromium.org> [modify] https://crrev.com/4f2f52d01d0cf062df2df35e3095a2f191f2d8af/net/bluetooth/hci_core.c [modify] https://crrev.com/4f2f52d01d0cf062df2df35e3095a2f191f2d8af/include/net/bluetooth/hci_core.h [modify] https://crrev.com/4f2f52d01d0cf062df2df35e3095a2f191f2d8af/net/bluetooth/mgmt.c
,
Dec 1 2016
The patch had been cherry-picked to the 4 kernel branches mentioned in Comment #41.
,
Dec 1 2016
The patch is now in all kernel branches in R55, R56, and ToT. Hence, I am closing this issue. Thanks.
,
Dec 16 2016
|
|||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||||||||||
Comment 1 by sdurais...@google.com
, Oct 12 2016