On Sat, Jan 20, 2024 at 12:34:27PM +0100, Stefan Wahren wrote: > Hi, > i recently noticed that the BCM2711 (used on Raspberry Pi 4) doesn't > implement pin_config_get, but this SOC is able to read back the bias > settings of the pins. After looking deeper into the pinconf_ops i had > some questions: > > 1. Are there any other benefits from implementing pin_config_get except > of a proper debugfs output? > Didn't reply to your previous sends of this question (or even read it TBH), as this is a pinctrl question, not GPIO, so not my area. >From the GPIO subsystem perspective, no, as gpiolib doesn't use the pinctrl API (defined in include/linux/pinctrl/pinconf.h), it uses the struct gpio_chip defined in include/linux/gpio/driver.h. That has no equivalent to the pinctrl pin_config_get. That perspective also applies to the character device uAPI and libgpiod, which provide the userspace interface to the GPIO subsystem/gpiolib. The value those return for the bias settings are what was set by the user when requesting the line, not what is set in the hardware (as we have no function to call to get it from the gpio_chip). And now I have something else I should add to the next version of the GPIO uAPI documentation that I'm working on. That doesn't rule out there being other benefits, but none from the GPIO perspective, AFAIAA. Cheers, Kent. > 2. Since the pin direction of BCM2835/2711 (input/output) is already > handled by pinmux_ops via gpio_set_direction, how should pin_config_set > handle PIN_CONFIG_OUTPUT_ENABLE? > > 3. In case pin_config_get is implemented should the parameter > PIN_CONFIG_OUTPUT_ENABLE and PIN_CONFIG_OUTPUT be handled? > > Best regards >