devicetree: Allow all GPIO flags to be used by devicetree

[vphirema]

Introduction

This section targets end users, TSC members, maintainers and anyone else that might
need a quick explanation of your proposed change.

Problem description

Why do we want this change and what problem are we trying to address?

Proposed change

support more GPIO flags in "include/dt-bindings/gpio/gpio.h"

Detailed RFC

GPIO flags in devicetree binding "include/dt-bindings/gpio/gpio.h" have only few GPIO flags.
For an Embedded Controller we need more GPIO flags to configure the devices of the system,
ideally GPIO flags available in "include/drivers/gpio.h". Hence, need to support more GPIO flags in "include/dt-bindings/gpio/gpio.h"

Proposed change (Detailed)

Adding more GPIO flags in dt-binding can be done in multiple ways

1. allow including the <drivers/gpio.h> this would need handling build errors as dt-binding doesn't allow
   typedefs, ints , enums etc
2. separate out the GPIO flags in <drivers/gpio.h> and include then in dt-binding
3. Move GPIO flags from <drivers/gpio.h> entirely to dt-binding

Dependencies

None, may deviate from standard Linux config

Concerns and Unresolved Questions

None

Alternatives

None

[pabigot]

This is contrary to policy about not deviating from Linux devicetree compatibility, so going to dev-review.

[galak]

This doesn't explain why the flags need to be in DTS v code?

[vphirema]

This doesn't explain why the flags need to be in DTS v code?

As the GPIO configuration are board specific (same GPIO can be open drain in one board and push pull in another board based on the design) . We can't handle the GPIO flags seamlessly in code if the plan is to define GPIOs in devicetree.

[pabigot]

But pull and open-drain flags are supported in devicetree bindings. What you can't specify is things like direction, which should be easy to provide in code at the point the GPIO is configured.

[vphirema]

But pull and open-drain flags are supported in devicetree bindings. What you can't specify is things like direction, which should be easy to provide in code at the point the GPIO is configured.

ACK, yes direction + interrupt modes

[pabigot]

So for that: I'm against this, because I haven't seen an argument that says why we need in devicetree any flags that aren't already supported. Why can't direction and interrupt mode be configured in code?

[vphirema]

So for that: I'm against this, because I haven't seen an argument that says why we need in devicetree any flags that aren't already supported. Why can't direction and interrupt mode be configured in code?

ACK, here are additional scenarios where we would need a robust devicetree if GPIOs are added in devicetree format

1. Same GPIO can be 1.8V or 3.3V on different platforms
   ex: Out from EC to Intel SOC, WARM_RESET signal on Geminilake is 1.8V while its 3.3V on Tigerlake
2. GPIO has to be pulled up by EC if it doesn't have external pull-ups
   ex: A volume up & down button need EC pullups or external pull-ups

rest of the input / output / interrupts can be handled in the code with multiple defines
ex:
inputs {
compatible = "gpio-keys";
aa: a{
label = "abc";
gpios = <&gpioa * xyz>;
};
}
outputs {
compatible = "gpio-keys";
bb: b{
label = "abc";
gpios = <&gpiod * xyz>;
};
}

c code might not look clean.
if coming from input
{set input}

if coming from input
{set output}

[vphirema]

this is the proposed PR with minimalist change to device tree file

db65d17

db65d17#diff-8c48a03ca88701931789a75b27aab77acd9d6ff11592f948cc71cbc2a9c0469f

[galak]

ACK, here are additional scenarios where we would need a robust devicetree if GPIOs are added in devicetree format

1. Same GPIO can be 1.8V or 3.3V on different platforms
   ex: Out from EC to Intel SOC, WARM_RESET signal on Geminilake is 1.8V while its 3.3V on Tigerlake
2. GPIO has to be pulled up by EC if it doesn't have external pull-ups
   ex: A volume up & down button need EC pullups or external pull-ups

Not sure I understand this case. Seems like we can specify that already with GPIO_PULL_UP

[vphirema]

ACK, here are additional scenarios where we would need a robust devicetree if GPIOs are added in devicetree format

1. Same GPIO can be 1.8V or 3.3V on different platforms
   ex: Out from EC to Intel SOC, WARM_RESET signal on Geminilake is 1.8V while its 3.3V on Tigerlake
2. GPIO has to be pulled up by EC if it doesn't have external pull-ups
   ex: A volume up & down button need EC pullups or external pull-ups

Not sure I understand this case. Seems like we can specify that already with GPIO_PULL_UP

sorry, pull-up is not a good example.

1. Inputs & outputs
2. interrupts
3. GPIO threshold levels (1.8V & 3.3V)
   are the examples.

[galak]

sorry, pull-up is not a good example.

1. Inputs & outputs
2. interrupts
3. GPIO threshold levels (1.8V & 3.3V)
   are the examples.

So I think we've covered 1 & 2. For 3 this would be a vendor specific flag and I don't have any particular issue with that.

[nandojve]

Is [3] referring to power-source property at https://www.kernel.org/doc/Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml?

[vphirema]

thank you all for the feedback.
I will close this request , will file a new request to handle 1.8V & 3.3V GPIOs