On Wed, Aug 20, 2025 at 10:13 AM Linus Walleij <linus.wall...@linaro.org> wrote:
> On Tue, Aug 19, 2025 at 8:31 PM Andy Shevchenko
> <andy.shevche...@gmail.com> wrote:
> > On Tue, Aug 19, 2025 at 4:02 PM Linus Walleij <linus.wall...@linaro.org> 
> > wrote:
> > > On Fri, Aug 15, 2025 at 11:09 AM Bartosz Golaszewski <b...@bgdev.pl> 
> > > 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

Reply via email to