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. ChenYu