On Wed, Aug 20, 2025 at 10:13 AM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > On Tue, Aug 19, 2025 at 8:31 PM Andy Shevchenko > <andy.shevchenko@xxxxxxxxx> wrote: > > On Tue, Aug 19, 2025 at 4:02 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > > > On Fri, Aug 15, 2025 at 11:09 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: ... > > > > devres: provide devm_kmemdup_const() > > > > pinctrl: ingenic: use struct pinfunction instead of struct function_desc > > > > pinctrl: airoha: replace struct function_desc with struct pinfunction > > > > pinctrl: mediatek: mt7988: use PINCTRL_PIN_FUNCTION() > > > > pinctrl: mediatek: moore: replace struct function_desc with struct pinfunction > > > > pinctrl: imx: don't access the pin function radix tree directly > > > > pinctrl: keembay: release allocated memory in detach path > > > > pinctrl: keembay: use a dedicated structure for the pinfunction description > > > > pinctrl: constify pinmux_generic_get_function() At least the above I'm pretty much okay with. Can you still have them being applied? > > > > pinctrl: make struct pinfunction a pointer in struct function_desc > > > > pinctrl: qcom: use generic pin function helpers > > > > pinctrl: allow to mark pin functions as requestable GPIOs > > > > > > I applied these 12 patches as a starter so they can > > > stabilize in linux-next. > > > > Hmm... I'm still sure that we don't need to have a separate flags > > field, but since I am on vacation and will be able to look at this > > closer next week, I can't look closer to it. > > The qualcomm 32bit platforms fail in next anyway so I dropped the patches > for now. > > Both you and Bartosz are on vacation so let's let it rest for a week or two. I will be available fully next week. -- With Best Regards, Andy Shevchenko