[PATCH V3 1/2] pinctrl: bcm2835: Implement bcm2835_pinconf_get

Chen-Yu Tsai wens at kernel.org
Wed Mar 6 05:40:53 PST 2024


On Wed, Mar 6, 2024 at 8:57 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Wed, Mar 6, 2024 at 9:55 AM Chen-Yu Tsai <wens at kernel.org> 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



More information about the linux-rpi-kernel mailing list