Open RomainPelletant opened 5 months ago
I am not sure HWINFO is the right place for this. While the reset cause can typically be obtained from one location in an SoC, the wakeup source cannot.
Thanks for your message. From this point of view, it makes no real sense to add it into hwinfo module.
This glue is close to hw so it shall be implemented in drivers, probably in a dedicated module.
Some flags should be cleaned up before going to sleep so an application API (or adding these calls in PM section) to correctly handle flags might be useful.
Finally, the more I think about it, the more I find interesting to get wake-up sources from DTS to handle flags cleanup "automatically".
I come back with few more details. In the meantime, if someone has good ideas : I'd be glad to read them :)
I made a PR proposal for GPIO wakeup in GPIO API. I don't see any other API already existing which could be relevant. No clear flag function. Do you see better way to implement it?
Is your enhancement proposal related to a problem? Please describe. AFAIK, there is no API to know the wakeup source.
Describe the solution you'd like hwinfo seems to be the right place as it is already used to provide reset cause.
It shall provide:
Wakeup source: GPIO, UART, I2C, SPI, CAN, RTC, USB, Ethernet, Bluetooth Fabrics like EXTI shall be processed in the same way? Do you see other types?
Provide the instance (bus or pin) that triggered the wakeup
Could be enabled by KCONFIG : CONFIG_HWINFO_WAKEUP_SOURCE_SUPPORT
In could be brought by pm_device.
Do you see any cases not covered by this -very simple- API? Adding custom field for extra informations?
Thanks for your support