Hi guys,
Am 06.03.24 um 14:40 schrieb Chen-Yu Tsai:
On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens@xxxxxxxxxx> wrote:
For the MediaTek device trees, the only two occurrences of "output-enable"
actually describe conflicting information:
pins-rts {
pinmux = <PINMUX_GPIO47__FUNC_URTS1>;
output-enable;
};
The above asks for the UART function on this pin, but based on existing
driver definitions, switches the function to GPIO output because of the
"output-enable" property. Hence the confusion.
This is actually also driver-dependent.
It is only conflicting if the pin controller has .strict set in struct
pinmux_ops,
because many SoCs are perfectly capable of using a pin as a function
such as UART RTS and GPIO at *the same time*.
I don't think MediaTek falls in this category. Nor does BCM2835. It is
quite obvious, since GPIO in/out are selectable pinmux functions.
Details on strict mode can be found in Documentation/driver-api/pin-control.rst
I don't know which Mediatek this is but:
$ git grep strict drivers/pinctrl/mediatek/
drivers/pinctrl/mediatek/pinctrl-moore.c: .strict = true,
Only the Moore family is strict, and I think BCM2835 is not.
While that would be true for new drivers, I believe we do have many existing
drivers that cannot set the strict bit, as existing device trees already
have their pinctrl options selecting the GPIO function in conjunction with
*-gpios usage. We also had this on older Allwinner platforms. We ended up
only setting the .strict option for new platforms, not because of any
hardware difference, but because of backwards compatibility. Otherwise
I would love to clean up many of them.
In both MediaTek and BCM2835's cases, it is quite obvious from the driver
that the hardware cannot use the pin as a dedicated function and a GPIO
at the same time. And we should not give them more options to shoot
themselves in the foot.
i tried following your discussion. Does it mean i should change anything
here in this series?
Best regards
ChenYu
