G'day Martyn, On 17/06/2019 16:29, Martyn Welch wrote:
Hi Linus, Bartosz, We are currently in the position that we would like to pre-configure some GPIOs at boot time and be able to later affect the state of GPIOs configured as outputs or read the state of GPIOs previously configured as inputs. The device tree property `gpios-line-names` gives a very useful mechanism for identifying the correct GPIO to use/read for a given purpose in user space, but doesn't provide any guidance on how that line is expected to be used. The gpio-hogging functionality enables us to configure GPIOs during boot, ensuring that the correct state is present on the relevant GPIO lines, but does not provide the ability to modify or read these GPIOs at runtime. I understand that a lot of people have requested such functionality in the past, but I'm not sure if anything concrete has ever been submitted. I'm interested in determining what the general feeling towards adding such functionality would be and to gain some input with regards to how this should/could be implemented (assuming the general concept is acceptable). Initially we are thinking of providing a device-tree node containing a "gpio-default" property and would contain a lot of the same properties as "gpio-hog". Code wise, it would seem to need to follow roughly the same flow as gpio-hog, but avoid running "gpiod_request_commit()" so that the GPIO line could later be requested by user space. I suspect there's a whole load of details that I'm missing at this stage and I've not fully thought through the implications for later removal. Does something like this seem viable upstream?
I'd find something like this useful. If we know enough to name the gpio lines, we more than likely also know enough to restrict the IO configuration to input only in the DT. There's a new driver recently posted that solves some of this: "Add virtual controller for gpio configuration" https://www.spinics.net/lists/linux-gpio/msg39681.html It solves a number of problems except for restricting user-space from configuring a pin for output that should never be an output. -- Regards Phil Reid
