On Tue, Oct 24, 2023 at 12:55 PM Cristian Marussi <cristian.marussi@xxxxxxx> wrote: > ...a maybe dumb question from my side, BUT does the SCMI Pinctrl carry > enough information as it stands for the driver to derive autonomously > and efficently the possible/applicable gpio ranges ? I don't know, that's part of the problem I suppose. But if the pin controller can report functions supported by certain pins or groups of pins, then certainly "gpio" should be one of those functions or else the pin cannot be used for GPIO at all? Then maybe that function is just a name convention, such as "all pins are members of a 1-pin group named 'gpioN' where N is the pin number" then you need to switch the pin into this function in order to use the pin as a GPIO line. Pins that do not have this group associated with them cannot be used for GPIO. This is incidentally exactly the method used by the Qualcomm pin control driver (IIRC). If the SCMI protocol has not though about GPIO as a special function, or mentioned anything about group name conventions for the GPIO function, then there is a hole in the specification, and this is likely best filled by creating one-pin groups as per above and feed this back to the spec. If the GPIO usecase isn't even considered a function by SCMI, or (more likely) "nobody thought about that" then this is a good time to send it back to the drawing board for specification, right? It's normal for specs to run into a bit of friction when confronted with the real world. Yours, Linus Walleij
