Skip to content

[SL-UP] Refactor Platform WiFi events - #1191

Draft
Rohan Sahay (rosahay-silabs) wants to merge 40 commits into
release_2.10-1.6.1from
refactor/platform-wifi-events
Draft

Rohan Sahay (rosahay-silabs) wants to merge 40 commits into
release_2.10-1.6.1from
refactor/platform-wifi-events

Conversation

@rosahay-silabs

@rosahay-silabs Rohan Sahay (rosahay-silabs) commented Sep 12, 2026

Copy link
Copy Markdown
Contributor

Summary

  • Move WiFi reconnect/retry out of WifiInterface into ConnectivityManagerImpl, so station connect/disconnect/reconnect is driven by one state machine.
  • Rename Silabs platform WiFi events (kWFXSystemEventkPlatformSLEvent, add public kSLSystemEvent) and replace ConfigureStationMode() with EnableStationMode().
  • Track last disconnect reason and map SiWx status codes to NetworkCommissioningStatusEnum (NC status reporting still has TODOs to use it).

Related issues

N/A

Testing

  • manually tested commissioning
  • reconnection of access point due to loss of access point
  • reconnection due to device reboot

…improved error handling and clarity. Simplify exit logic by removing unnecessary exit label.
… handling to streamline the connection process.
…tials if the station is provisioned before connecting to a new network. Add comments for clarity on the connection process.
…essages for WiFi events and streamline state transitions by removing unnecessary checks. Enhance error handling in setting WiFi station mode and improve clarity in DriveStationState logic.
…itialize mLastDisconnectionReason to kUnknownError for improved error tracking.
Map join/disconnect failures to disconnection reasons and let ConnectivityManager drive station state.
Map join/disconnect failures to disconnection reasons and let ConnectivityManager drive station state.
@silabs-matter-ci-bot silabs-matter-ci-bot Bot added the sl-up This TAG indicates that this commit needs to be upstreamed to CSA before its next release. label Sep 12, 2026
Comment thread src/platform/silabs/wifi/SiWx/WifiInterfaceImpl.cpp Outdated
Comment on lines +747 to +749
WifiInterfaceImpl & self = WifiInterfaceImpl::GetInstance();
self.mLastDisconnectionReason = reason;
self.NotifyDisconnection(self.mLastDisconnectionReason);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

would this. work here or is this a static function? If so, does it need to be static?

Suggested change
WifiInterfaceImpl & self = WifiInterfaceImpl::GetInstance();
self.mLastDisconnectionReason = reason;
self.NotifyDisconnection(self.mLastDisconnectionReason);
this.mLastDisconnectionReason = reason;
this.NotifyDisconnection(self.mLastDisconnectionReason);

CHIP_ERROR WifiInterfaceImpl::EnableStationMode()
{
wfx_rsi.dev_state.Set(WifiState::kStationMode);
return CHIP_NO_ERROR;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it can't fail why do we need a return code?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Typically going by implementation of us and peers, we should have a way to enable and disable station mode, which should be a platform API call and not just setting a state, hence changing it to a CHIP_ERROR return instead of a void, we do have an API on SiWx917 platform as well but I have not explored that yet.

return CHIP_NO_ERROR;
}

chip::app::Clusters::NetworkCommissioning::NetworkCommissioningStatusEnum

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you have a using namespace chip::app::Clusters::NetworkCommissioning; in this file. You should be able to shorthen this to

Suggested change
chip::app::Clusters::NetworkCommissioning::NetworkCommissioningStatusEnum
NetworkCommissioningStatusEnum

kIPBindFailed
kUnknownError
*/
using Status = chip::app::Clusters::NetworkCommissioning::NetworkCommissioningStatusEnum;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the same reason stated above. I think

NetworkCommissioningStatusEnum::kSuccess;
NetworkCommissioningStatusEnum::kNetworkNotFound;
...

would work if you want to keep the using Status it can be shortened too

GetWiFiStationMode();
// if the station mode is application controlled or disabled, return
VerifyOrReturn(stationMode != kWiFiStationMode_ApplicationControlled,
ChipLogError(DeviceLayer, "WiFi station mode is application controlled"));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

similar comment than before. Is this an Error? Also it seems this would be printed a lot. DriveStationState runs often no?

Comment on lines +243 to +244
WifiInterface::GetInstance().TriggerDisconnection();
ChangeWiFiStationState(kWiFiStationState_Disconnecting);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

like i mentioned before. Should be regrouped.

// Cannot use the driver if the instance is not initialized.
VerifyOrDie(nwDriver != nullptr); // should never be null
nwDriver->UpdateNetworkingStatus();
case kWiFiStationState_Connecting_Succeeded:

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is kWiFiStationState_Connecting_Succeeded needed? Can't just go to Connected?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I have the same doubt kWiFiStationState_Connecting_Succeeded vs kWiFiStationState_Connected, but I did not find any concrete documentation for the differences in those states.
My initial impressions were that maybe kWiFiStationState_Connecting_Succeeded would be for the WiFi connection on the access point level, where we are connected but the IP stack is negotiating, but that logic fails since we have a connectivity event to track that state.
I will look into how others are using it and infer from there.

break;

default:
ChipLogDetail(DeviceLayer, "WiFi station state not driving: %s", WiFiStationStateToStr(newState));

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will still schedule a DriveStationState for an unkown state

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added this log to verify that we are scheduling for all known state, more of a verification log rather than anything else.

ChipLogDetail(DeviceLayer, "WiFi station state not driving: %s", WiFiStationStateToStr(newState));
break;
}
TEMPORARY_RETURN_IGNORED DeviceLayer::SystemLayer().ScheduleWork(DriveStationState, NULL);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The sequence seems odd to me.
DriveStationState calls ChangeWiFiStationState in most situation. And ChangeWiFiStationState will then call DriveStationState again.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right now, we are doing it for the TriggerDisconnection is not having a callback to show the disconnecting state, same for the connecting state, adding the ChangeWiFiStationState instead of a mStationState because the former would not process the same state twice. The only place I have prefer not doing this is the reconnection logic, where though it will work, we will end of queuing the DriveStationState twice, once by ChangeWiFiStationState another time with the delay of timer.

The retry logic is the only place I would not call ChangeWiFiStationState, other places I would still prefer invoking the ChangeWiFiStationState.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

sl-up This TAG indicates that this commit needs to be upstreamed to CSA before its next release.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants