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

[Chen-Yu Tsai <wens@xxxxxxxxxx>]

On Thu, Mar 7, 2024 at 1:04 AM Stefan Wahren <wahrenst@xxxxxxx> wrote:
>
> 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?

I think support for PIN_CONFIG_INPUT_ENABLE and PIN_CONFIG_OUTPUT_ENABLE
should be dropped from the series.

ChenYu