Re: [RFC 4/4] dt-bindings: gpio: Add bindings for SCMI pinctrl based gpio

[AKASHI Takahiro <takahiro.akashi@xxxxxxxxxx>]

Hi Rob, Cristian,

On Mon, Oct 02, 2023 at 03:58:27PM +0100, Cristian Marussi wrote:
> On Mon, Oct 02, 2023 at 09:41:55AM -0500, Rob Herring wrote:
> > On Mon, Oct 02, 2023 at 11:16:02AM +0900, AKASHI Takahiro wrote:
> > > A dt binding for SCMI pinctrl based gpio driver is defined in this
> > > commit. It basically conforms to generic pinctrl-gpio mapping framework.
> 
> [ snip]
> 
> > > +    additionalProperties: false
> > > +
> > > +required:
> > > +  - compatible
> > > +  - gpio-controller
> > > +  - "#gpio-cells"
> > > +  - gpio-ranges
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > +  - |
> > > +    #include <dt-bindings/gpio/gpio.h>
> > > +
> > > +    scmi_gpio_0: scmi_gpio@0 {
> > 
> > gpio {
> > 
> > But doesn't SCMI have protocol numbers?
> > 
> 
> My understanding is that this RFC GPIO driver from Akashi is built
> completely on Pinctrl facilities (as he says in the cover), it is not
> indeed a typical pure SCMI driver, it just happen to trigger the use
> of SCMI if the underlying backend pinctrl driver is pinctrl-scmi;
> but this driver does not really call directly into any SCMI API by
> itself, i.e. it does not get and call any SCMI protocol ops.
> (but it could indeed trigger the backend Pinctrl SCMI driver to issue
>  such call on its behalf AFAIU...)

It would be possible to implement this driver by directly using SCMI
pinctrl interfaces (I mean drivers/firmware/arm,scmi/pinctrl.c)
if the system wants to utilize SCMI solely for GPIO accesses and doesn't
need pinctrl support.
(Even so, "protocol@19" will be required due to the current SCMI binding.)

But I didn't take this approach because the kernel's pinctrl framework
(and many existing pinctrl drivers) instead adopts standard pinctrl-
gpio mapping (I mean gpiolib(-of).c) and it just seems to work well.

> I wonder why it has even a dependency on PINCTRL_SCMI at this point;
> is not that it could work (generically) even if the backend Pinctrl
> driver is NOT SCMI ?
> What makes it usable only against an SCMI Pinctrl backend ?
> Cannot be a generic GPIO driver based on top of Pinctrl, no matter which
> Pinctrl backend driver has been configured ?

That is one of my questions (See the issue (3) in my cover letter.)
Why doesn't there exist a generic GPIO driver of this kind (based on gpiolib
framework) even though it could apparently be possible?

I guess that there a couple of reasons:
1) As I mentioned in the issue (1) in my cover letter, the current
  framework doesn't present an interface, especially for obtaining
  a value on a gpio input pin. Then it enforces each pinctrl-based gpio
  driver needs to have its own driver.
2) Furthermore, there may be driver-specific semantics required,
  say, for pinconf-related configurations? (I don't come up with any
  example, though)

If my driver is good enough for applying to other gpio controllers as well,
I would not hesitate to name it a genuine generic driver whether the backend
may be SCMI or not.
        -> Linus, comment here please.

Due to possible cases of (2), I still added "-generic" postfix to the
"compatibles" property so that other variant drivers may be tagged as
"arm,scmi-gpio-some-system" or "some-vendor,scmi-gpio".

Thanks,
-Takahiro Akashi

> 
> ...I maybe missing something here about Pinctrl AND GPIO frameworks :P
> 
> Thanks,
> Cristian