syscon: Add USB accessory power rail API signatures and stubs - #387
Conversation
denisuntila
commented
Sep 15, 2026
denisuntila
commented
- Added NID 0x47378317 (sceSysconCtrlUsbPower) and 0xEB11E9DE (sceSysconGetUsbPowerCtrl)
- Tested and verified working on hardware
- Added NID 0x47378317 (sceSysconCtrlUsbPower) and 0xEB11E9DE (sceSysconGetUsbPowerCtrl) - Tested and verified working on hardware
GrayJack
left a comment
GrayJack
left a comment
There was a problem hiding this comment.
Good work. I have some questions and noticed the NID values are wrong (for the PSPSDK).
| #ifdef F_sceSyscon_driver_0114 | ||
| IMPORT_FUNC "sceSyscon_driver", 0x47378317, sceSysconCtrlUsbPower | ||
| #endif | ||
| #ifdef F_sceSyscon_driver_0115 | ||
| IMPORT_FUNC "sceSyscon_driver", 0xEB11E9DE, sceSysconGetUsbPowerCtrl | ||
| #endif |
There was a problem hiding this comment.
The NIDs are wrong, for the PSPSDK the NID must be the one from the lowest firmware where the stub is available.
These are the NID for those functions on the FW >= 6.60
There was a problem hiding this comment.
The fw 3.00 NIDs for those functions are respectively 0x3987FEA3 and 0xEE81C5B1 according to the psplibdoc, but i can't test them.
If you have time can you please explain me how does the nid resolve work for later versions (when you compile something for a higher firmware), or give me indications on where i can learn about that?
There was a problem hiding this comment.
Most CFW takes the task to translate old kernel NID to new kernel NID. They basically have a table of old NID (in PSPSDK, or commonly used even withou the SDK) and it's correct value on the CFW supported firmware.
I also recommend to at least request for the maintained CFWs to include these in their translation table it they are not already.
The ones that are currently maintained is ARK-5 and Epinephrine (Adrenaline's default eCFW).
In this particular case , it is not a issue for Epinephrine, since VITA has no sceSyscon_driver, but for ARK-5, that supports both PSP and VITA PSPemu, it probably is
There was a problem hiding this comment.
does PRO-C2 do that translation too? that's the one i use, since ARK-5 appears a lot more bloated. if it doesn't, the recent NID modifications to target older NIDs would likely break pspsdk-built programs for me.
There was a problem hiding this comment.
Yes, it does, most CFW does. It is a important feature if the CFW wants to:
- Support kernel plugins build with PSPSDK
- Support for closed-source kernel plugins (focusnon the ones no longer maintained, like CWCheat)
That being said, there is a chance unmaintained CFW may not have these specific ones being added here, but you can always fork PRO and added it in such cases.
I don't know about recent kernel NID change in PSPSDK, using the oldest kernel NID for kernel stubs is the PSPSDK policy since forever (way before I syarted to get involved)
| * @param power 1 to turn on, 0 to turn off | ||
| * @return 0 if success, < 0 otherwise | ||
| */ | ||
| int sceSysconCtrlUsbPower(s8 power); |
There was a problem hiding this comment.
Since the parameter can only be 0 or 1, makes more sense for the parameter type to be u8
| * Gets the power status of the USB accessory port (PSP Cam, GPS, etc.). | ||
| * @return 1 if powered on, 0 otherwise | ||
| */ | ||
| int sceSysconGetUsbPowerCtrl(void); |
There was a problem hiding this comment.
Is the return guaranteed to be 0 or 1 for this function? If it does, it is ok to put u8 as the return type
- Changed NIDs with the fw 3.00 ones - Modified the signatures with the proper types
3 participants
