On Tue, Sep 2, 2025 at 4:46 PM Andy Shevchenko <andriy.shevchenko@xxxxxxxxx> 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
