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

[Stefan Wahren]

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 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.
i tried following your discussion. Does it mean i should change anything
here in this series?

Best regards
>
>
> ChenYu