linux-kernel - Re: [PATCH 2/3] pinctrl: ls2k0300: Support Loongson 2K0300 SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aKRw1pEUUwd4cQoW@pie>
Date: Tue, 19 Aug 2025 12:40:54 +0000
From: Yao Zi <ziyao@...root.org>
To: Linus Walleij <linus.walleij@...aro.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Huacai Chen <chenhuacai@...nel.org>,
	WANG Xuerui <kernel@...0n.name>, linux-gpio@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	loongarch@...ts.linux.dev, Mingcong Bai <jeffbai@...c.io>,
	Kexy Biscuit <kexybiscuit@...c.io>
Subject: Re: [PATCH 2/3] pinctrl: ls2k0300: Support Loongson 2K0300 SoC

On Tue, Aug 19, 2025 at 12:02:23PM +0200, Linus Walleij wrote:
> On Mon, Aug 11, 2025 at 6:39 PM Yao Zi <ziyao@...root.org> wrote:
> 
> > Support pin multiplexing and drive-strength setting for Loongson 2K0300
> > SoC. Pin multiplexing could be done separately for each pin, while
> > drive-strength could be only configured on function basis. This differs
> > a lot from the driver for previous generation of Loongson SoC, where
> > pinmux setting is based on group.
> >
> > Pins are represented with pinmux properties in devicetrees, and we use
> > the generic pinmux API for parsing. The common pinconf interface isn't
> > used for drive-strength setting, since it handles pinconf settings at a
> > unit of pin groups or smaller.
> >
> > Instead, the driver configures drive-strength settings just after
> > parsing the devicetree. The devicetree's structure ensures no conflicts
> > could happen in drive-strength settings.
> >
> > Signed-off-by: Yao Zi <ziyao@...root.org>
> 
> Overall the driver looks very good, well done!
> 
> Look into Rob's comment on the bindings to use a single node
> for mux and config.

I've raised several questions about the binding and will change the
binding and code according to Rob's answer.

> I saw that you want to make the pin controller strict, if you also have
> some pins with "GPIO mode" that will serve as back-end for a
> GPIO driver (and I saw you posted a GPIO driver series as well)
> then have a look at Bartosz recent patches to add infrastructure
> for pinctrl to know about what a GPIO pin is:
> https://lore.kernel.org/linux-gpio/20250815-pinctrl-gpio-pinfuncs-v5-0-955de9fd91db@linaro.org/T/

Thanks for the link! Actually according to the manual, all the 106 on
2K0300 pins could be multiplexed as GPIO. But the pinctrl cannot set up
any pin config for pins in GPIO mode.

> The current driver does not seem to know about any of these
> pins being usable as GPIO and does not implement those:
> 
>         int (*gpio_request_enable) (struct pinctrl_dev *pctldev,
>                                     struct pinctrl_gpio_range *range,
>                                     unsigned int offset);
>         void (*gpio_disable_free) (struct pinctrl_dev *pctldev,
>                                    struct pinctrl_gpio_range *range,
>                                    unsigned int offset);
>         int (*gpio_set_direction) (struct pinctrl_dev *pctldev,
>                                    struct pinctrl_gpio_range *range,
>                                    unsigned int offset,
>                                    bool input);
>         bool strict;
> 
> Which is fine if the pins actually cannot be used for GPIO, but if they
> can, and this is just implicit for unconfigured pins ... then add
> functions and groups for GPIO.

For 2K0300, we want these pins to be able to multiplexed as GPIOs, but
since this pinctrl driver could configure nothing for GPIO mode pins, I
think it's enough to implement only the gpio_request_enable() callback
and do the multiplexing work here, is this correct?

I originally thought it's okay to multiplex pins as GPIO with an usual
pinctrl configuration, and didn't realize that it causes conflicts on
strict controllers since the pin will be claimed by both pincontroller
and GPIO controller. Thanks for the reminder.

> The other driver using pinconf_generic_parse_dt_pinmux()
> drivers/pinctrl/meson/pinctrl-amlogic-a4.c has GPIO awareness.
> 
> Yours,
> Linus Walleij
> 

Much thanks for the detailed guidance!

Best regards,
Yao Zi