On Tue, Sep 2, 2025 at 4:46 PM Andy Shevchenko andriy.shevchenko@intel.com wrote:
On Tue, Sep 02, 2025 at 01:59:09PM +0200, Bartosz Golaszewski wrote:
Problem: when pinctrl core binds pins to a consumer device and the pinmux ops of the underlying driver are marked as strict, the pin in question can no longer be requested as a GPIO using the GPIO descriptor API. It will result in the following error:
[ 5.095688] sc8280xp-tlmm f100000.pinctrl: pin GPIO_25 already requested by regulator-edp-3p3; cannot claim for f100000.pinctrl:570 [ 5.107822] sc8280xp-tlmm f100000.pinctrl: error -EINVAL: pin-25 (f100000.pinctrl:570)
This typically makes sense except when the pins are muxed to a function that actually says "GPIO". Of course, the function name is just a string so it has no meaning to the pinctrl subsystem.
We have many Qualcomm SoCs (and I can imagine it's a common pattern in other platforms as well) where we mux a pin to "gpio" function using the `pinctrl-X` property in order to configure bias or drive-strength and then access it using the gpiod API. This makes it impossible to mark the pin controller module as "strict".
This series proposes to introduce a concept of a sub-category of pinfunctions: GPIO functions where the above is not true and the pin muxed as a GPIO can still be accessed via the GPIO consumer API even for strict pinmuxers.
To that end: we first clean up the drivers that use struct function_desc and make them use the smaller struct pinfunction instead - which is the correct structure for drivers to describe their pin functions with. We also rework pinmux core to not duplicate memory used to store the pinfunctions unless they're allocated dynamically.
First: provide the kmemdup_const() helper which only duplicates memory if it's not in the .rodata section. Then rework all pinctrl drivers that instantiate objects of type struct function_desc as they should only be created by pinmux core. Next constify the return value of the accessor used to expose these structures to users and finally convert the pinfunction object within struct function_desc to a pointer and use kmemdup_const() to assign it. With this done proceed to add infrastructure for the GPIO pin function category and use it in Qualcomm drivers. At the very end: make the Qualcomm pinmuxer strict.
I read all this and do not understand why we take all this way, Esp. see my Q in patch 16. Can we rather limit this to the controller driver to decide and have it handle all the possible configurations, muxing, etc?
I think what we are trying to do here is to delegate part of the driver's work pin mux / pin control core. While it sounds like right direction the implementation (design wise) seems to me unscalable.
In any case first 12 patch (in case they are not regressing) are good to go as soon as they can. I like the part of constification.
I'm not sure how to rephrase it. Strict pinmuxers are already a thing, but on many platforms it's impossible to use them BECAUSE pinctrl doesn't care about what a function does semantically. It just so happens that some functions are GPIOs and as such can also be used by GPIOLIB. Except that if the pinmuxer is "strict", any gpiod_get() call will fail BECAUSE pinctrl does not know that a function called "gpio" is actually a GPIO and will say NO if anything tries to request a muxed pin. This (the function name) is just a string, it could as well be called "andy" for all pinctrl cares. This is why we're doing it at the pinctrl core level - because it will benefit many other platforms as Linus mentioned elsewhere - he has some other platforms lined up for a similar conversion. And also because it cannot be done at the driver level at the moment, it's the pinctrl core that says "NO" to GPIOLIB. I think you missed the entire point of this series.
Bartosz