-
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1836,10 +1836,11 @@ GenericThreadStackManagerImpl_OpenThread<ImplClass>::SetSEDIntervalMode(Connecti | |
{ | ||
return CHIP_ERROR_INVALID_ARGUMENT; | ||
} | ||
mIntervalsMode = intervalType; | ||
|
||
Impl()->LockThreadStack(); | ||
|
||
mIntervalsMode = intervalType; | ||
|
||
// For Thread devices, the intervals are defined as: | ||
// * poll period for SED devices that poll the parent for data | ||
// * CSL period for SSED devices that listen for messages in scheduled time slots. | ||
|
@@ -1879,10 +1880,9 @@ GenericThreadStackManagerImpl_OpenThread<ImplClass>::SetSEDIntervalMode(Connecti | |
} | ||
|
||
template <class ImplClass> | ||
CHIP_ERROR GenericThreadStackManagerImpl_OpenThread<ImplClass>::_RequestSEDActiveMode(bool onOff) | ||
CHIP_ERROR GenericThreadStackManagerImpl_OpenThread<ImplClass>::_RequestSEDActiveMode(bool onOff, bool delayIdle) | ||
jepenven-silabs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
{ | ||
CHIP_ERROR err = CHIP_NO_ERROR; | ||
ConnectivityManager::SEDIntervalMode mode; | ||
|
||
if (onOff) | ||
{ | ||
|
@@ -1894,13 +1894,43 @@ CHIP_ERROR GenericThreadStackManagerImpl_OpenThread<ImplClass>::_RequestSEDActiv | |
mActiveModeConsumers--; | ||
} | ||
|
||
if (!onOff && delayIdle && CHIP_DEVICE_CONFIG_SED_ACTIVE_THRESHOLD.count() != 0) | ||
{ | ||
err = DeviceLayer::SystemLayer().StartTimer(CHIP_DEVICE_CONFIG_SED_ACTIVE_THRESHOLD, RequestSEDModeChange, this); | ||
if (CHIP_NO_ERROR == err) | ||
{ | ||
return err; | ||
} | ||
|
||
ChipLogError(DeviceLayer, "Failed to postponed Idle Mode with error %" CHIP_ERROR_FORMAT, err.Format()); | ||
jepenven-silabs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} | ||
|
||
return SEDChangeMode(); | ||
} | ||
|
||
template <class ImplClass> | ||
CHIP_ERROR GenericThreadStackManagerImpl_OpenThread<ImplClass>::SEDChangeMode() | ||
jepenven-silabs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
{ | ||
CHIP_ERROR err = CHIP_NO_ERROR; | ||
ConnectivityManager::SEDIntervalMode mode; | ||
|
||
mode = mActiveModeConsumers > 0 ? ConnectivityManager::SEDIntervalMode::Active : ConnectivityManager::SEDIntervalMode::Idle; | ||
|
||
if (mIntervalsMode != mode) | ||
err = SetSEDIntervalMode(mode); | ||
|
||
return err; | ||
} | ||
|
||
template <class ImplClass> | ||
void GenericThreadStackManagerImpl_OpenThread<ImplClass>::RequestSEDModeChange(chip::System::Layer * apSystemLayer, | ||
jepenven-silabs marked this conversation as resolved.
Show resolved
Hide resolved
|
||
void * apAppState) | ||
{ | ||
if (apAppState != nullptr) | ||
{ | ||
static_cast<GenericThreadStackManagerImpl_OpenThread *>(apAppState)->SEDChangeMode(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 commentThe 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 commentThe 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... |
||
} | ||
} | ||
#endif | ||
|
||
template <class ImplClass> | ||
|
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?