Chris Johns commented on a discussion: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/121#note_111046 Reset can be overridden by an app by overriding the call using the linker. An example is a Zynq app I know of where the hardware uses a watchdog to override the default reset behavior because the SoC generate reset does not drive POR low. The system level requirement is all hardware must be reset by software. This change sort of breaks that decade old application. You could argue the additional arguments will be ignored. I would rather we acknowledge that rather than ignore it. The other problem is deciding if these `bootcard` calls are interfaces we need to maintain? I do not have an answer for this because it is double edged and can cut both ways. I like `void bsp_reset(void)` because it is clearly about performing a reset and nothing more. The addition of the options implies extra functionality. Do the arguments mean there can optionally be an extra layer added in a BSP before the actual reset is performed? What do you see the arguments being used for? I also noticed BSPs have slightly different signatures, some with attributes? Does this means the function signature is BSP specific? -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/121#note_111046 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list bugs@rtems.org http://lists.rtems.org/mailman/listinfo/bugs
