On Wed, Jul 30, 2025 at 2:50 PM Andy Shevchenko
<andy.shevche...@gmail.com> wrote:
>
> On Wed, Jul 30, 2025 at 11:54 AM Bartosz Golaszewski <b...@bgdev.pl> wrote:
> >
> > On Thu, Jul 24, 2025 at 2:22 PM Andy Shevchenko
> > <andy.shevche...@gmail.com> wrote:
> > >
> > > > struct pinfunction {
> > > > const char *name;
> > > > const char * const *groups;
> > > > size_t ngroups;
> > > > + unsigned long flags;
> > >
> > > Not sure we need this. If the function is GPIO, pin control already
> > > knows about this. The pin muxing has gpio request / release callbacks
> > > that change the state. Why do we need an additional flag(s)?
> > >
> >
> > I'm not following, how does the pin controller know that the function
> > is GPIO exactly, other than by the bit set in this field?
>
> AFAICS the gpio_owner != NULL means that. No need to have a duplicate
> of this information.
>
No, that's not at all what this series does... gpio_owner is the
consumer label of a pin used by the GPIOLIB framework. The flag I'm
introducing it telling the pinctrl core - before GPIOLIB is ever
involved - that *this pin can be requested as a GPIO by GPIOLIB*. It's
the other way around - without knowing this, for strict pinmuxers,
GPIOLIB would never be able to request this pin if it was muxed to a
function (even if the function is called "GPIO").
Bart
