Chris Johns commented on a discussion on cpukit/include/dev/gpio/gpio.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159803 > + * > + * What a pin reads as before rtems_gpio_pin_configure() is called on it, > + * and what it returns to after rtems_gpio_pin_release(). > + */ > + RTEMS_GPIO_DIRECTION_NONE = 0, > + > + /** > + * @brief This enumerator indicates that the pin is an input. > + */ > + RTEMS_GPIO_DIRECTION_INPUT, > + > + /** > + * @brief This enumerator indicates that the pin is an output. > + */ > + RTEMS_GPIO_DIRECTION_OUTPUT > +} rtems_gpio_direction; Currently the design is an unused or disabled pin is not part of the logical set of pin exposed to the API. I saw the role of determining the pin set exposed to the API as happening in the BSP and at the BSP level INI configs or other means can be used to determine the enabled set. If a design has a pin in a disabled, low power or what ever state it would not be available. @c-mauderer I can see your point where the BSP and driver has exposed all pin and apps could vary their usage. Both cases are valid. I think using `RTEMS_GPIO_DIRECTION_NONE` to be a disable can fill the role. No direction implies no ability to control which means disabled. The BSP and it's driver can implement what ever mode that suites the hardware. @amar this `enum` is for direction and low power is not a direction. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1499#note_159803 You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/namespace/49/sent_notifications/5-3ojxyb8dkn42uumwnp1s5eg71-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
