SIM Hot-Swap Detection Issue in Fibocom Modem Plugin

[Yannick Serafini]

Hello ModemManager maintainers,

I'm currently developing a Fibocom modem plugin for ModemManager and encountering an issue with SIM hot-swap detection that I'd like to get your insights on.

# Issue Description
When implementing the SIM hot-swap detection functionality, I've observed inconsistent behaviour under certain conditions:
- In normal single insertion/removal cases, the detection works correctly
- However, when rapidly inserting and removing the SIM card multiple times (ending with the SIM inserted), ModemManager sometimes incorrectly reports the SIM as missing even though it's physically present
- This issue also occurs occasionally in normal usage scenarios without excessive manipulation, though less frequently (the rapid insertion/removal scenario is mainly a way to reproduce the bug more consistently)

# Technical Details
My implementation follows the standard ModemManager architecture for handling SIM events:
1. A callback configures the modem to notify MM asynchronously of SIM insertion/removal
2. When these asynchronous events are detected, another callback is invoked which calls mm_iface_modem_process_sim_event
3. This eventually calls mm_base_modem_set_reprobe to trigger a complete modem reprobe

I've modeled this implementation after the ublox modem plugin which handles similar functionality.

# Analysis
Based on my investigation, it appears that during multiple rapid insertions/removals, ModemManager begins a "modem reprobe" cycle. If it attempts to detect the SIM status while the card is temporarily removed or making poor contact, it enters an error state. Even when the SIM is subsequently fully inserted, MM remains in this error state and reports the SIM as missing.
The issue can sometimes occur even without excessive manipulation, possibly due to poor physical contacts during normal insertion (suggesting a debouncing issue might be involved).

# Questions
1. Is this a known issue with SIM hot-swap detection in ModemManager? Maybe not considered as an issue?
2. Are there recommended approaches to handle this race condition or improve the robustness of SIM detection during reprobe cycles?
3. Would implementing additional debouncing or verification logic in the plugin be appropriate, or should this be addressed at the ModemManager core?
4. Would it make sense to implement a polling callback shortly after a SIM detection failure? This could verify the SIM status again after a brief delay to catch cases where the SIM was in transition during the initial check.

Any guidance or suggestions would be greatly appreciated. 
I'm happy to provide additional details or testing results if needed.

Thank you for your time,
Yannick Serafini
Wifx SA