We can implement device_set_wakeup_capable() in the !CONFIG_PM_SLEEP
case; we do not have the infrastructure in place for the CONFIG_PM_SLEEP
case so leave a pr_debug TODO.
Needed by an upcoming wireless driver.
MFC after: 3 days
Details
Details
This will likely need to go along a __FreeBSD_version bump
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 75639 Build 72522: arc lint + arc unit
Event Timeline
| sys/compat/linuxkpi/common/include/linux/pm.h | ||
|---|---|---|
| 124–128 | Out of curiosity, why did you prefer a static inline function here instead of a #define like we do in many places? | |
| sys/compat/linuxkpi/common/include/linux/pm.h | ||
|---|---|---|
| 124–128 | IMO, all else being equal we should prefer static inline functions. They avoid the potential pitfalls of macros (multiple evaluation of arguments, possibly confusing precedence, obfuscating debug info, etc.) without introducing a performance penalty. | |
| sys/compat/linuxkpi/common/include/linux/pm.h | ||
|---|---|---|
| 124–128 | I also prefer the static inline approach over the macro, even if it is more verbose. | |
| sys/compat/linuxkpi/common/include/linux/pm.h | ||
|---|---|---|
| 124–128 | That said the reason probably were that I am used to from LinuxKPI 802.11 (sometimes multiple inline functions will call the same implementation with different arguments; initially I just need something to hold the "TODO()"). But you can also add __unused and other annotations. Lastly I am not 100% sure macros are always fully type preserving (I should really go and read up in a modern C standard on that). | |