-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ICD] Initial Impl Active Threshold #24394
[ICD] Initial Impl Active Threshold #24394
Conversation
PR #24394: Size comparison from b36439e to fa239ed Increases (15 builds for bl702, cc13x2_26x2, esp32, k32w, nrfconnect, psoc6, qpg, telink)
Decreases (13 builds for bl602, bl702, cc13x2_26x2, cyw30739, esp32, nrfconnect, psoc6, telink)
Full report (54 builds for bl602, bl702, cc13x2_26x2, cyw30739, efr32, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.cpp
Outdated
Show resolved
Hide resolved
src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.cpp
Outdated
Show resolved
Hide resolved
src/platform/OpenThread/GenericThreadStackManagerImpl_OpenThread.cpp
Outdated
Show resolved
Hide resolved
fa239ed
to
dc8ccce
Compare
PR #24394: Size comparison from 58e20ec to dc8ccce Increases (13 builds for cc13x2_26x2, cyw30739, k32w, psoc6, telink)
Decreases (7 builds for cc13x2_26x2, esp32, psoc6, telink)
Full report (49 builds for bl602, bl702, cc13x2_26x2, cyw30739, esp32, k32w, linux, mbed, nrfconnect, psoc6, qpg, telink)
|
* Spec section 2.12.5 | ||
*/ | ||
#ifndef CHIP_DEVICE_CONFIG_SED_ACTIVE_THRESHOLD | ||
#define CHIP_DEVICE_CONFIG_SED_ACTIVE_THRESHOLD System::Clock::Milliseconds32(4000) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason this wasn't 4000_ms32
like other things in this file?
{ | ||
if (apAppState != nullptr) | ||
{ | ||
static_cast<GenericThreadStackManagerImpl_OpenThread *>(apAppState)->SEDChangeMode(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks wrong to me.
Let's say we go into active mode for an exchange, and then the exchange completes. We will start a timer to call this function.
If, before the timer fires, we enter active mode for some reason other than an exchange and then exit active mode, we will exit immediately, without waiting for this timer to fire.
What I think we need to do is that the timer starting successfully, if there was no timer so far, should count as an active mode consumer (and increase mActiveModeConsumers by 1). When the timer fires it should then decrement mActiveModeConsumers by 1.
Or something else to deal with this problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bzbarsky-apple It's not a problem as per the spec. section 2.12.5 specify SHOULD stay active, the case you've described is a possible corner case that doesn't go against this implementation. However this would have to be address when the Client Monitoring cluster will fully be implemented.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This behavior is allowed by the spec, but it's still not the intended behavior of this implementation as far as I can tell...
* Initial Impl Active Threshold * Apply comments
Partial fix of #24260
Implement sections 2.12.5 which is in direct contradiction with section 11.24.5.3 of the same spec (Global constant vs cluster attribute).
Main differences are that current implementation is based on a hard coded threshold value and respect the SHOULD instead of the SHALL. Meaning that in the rare corner case where no timer are available to postponed the Idle mode, a device COULD go to Idle mode immediately which is in accordance with section 2.12.5.
Tested on Silabs EFR32 platform