[PATCH v2 03/22] pinctrl: pinctrl-generic: Make the "function" property optional
Changhuang Liang
changhuang.liang at starfivetech.com
Thu May 14 22:55:48 PDT 2026
Hi, Conor
Thanks for the review.
> On Thu, May 14, 2026 at 04:11:59AM -0700, Changhuang Liang wrote:
> > Some pinctrl subnodes only need to configure pin properties (e.g.,
> > power-source, bias, drive strength) without assigning any mux function.
> >
> > Currently, the driver requires a valid "function" property for all
> > pinctrl subnodes. This forces the addition of dummy or redundant
> > "function" entries when only pin configuration is needed.
> >
> > Example use case:
> > gpios-configs {
> > config {
> > pins = <0 1 2 3>;
> > power-source = <0>;
> > };
> > };
> >
> > Make the "function" property optional. If it is missing, skip adding
> > the mux map and only process the pin configuration.
>
> I looked through the series though and all controllers appear to have pins and
> functions, is it the case that gpio is the default for these pins, so you are
> omitting the functions property when you are using the pin in gpio mode?
> Saying that the functions property is "redudant" makes it seem like this might
> be the case?
>
> I've got some feedback here, but I can't really provide it without knowing the
> answer to that question.
"From v1, copying Linus's suggestion:
> + This domain contains 4 IO groups which support voltage levels 1.8V and 3.3V
> + gpioe-spi - comprises PAD_GPIO_C0 through PAD_GPIO_C4.
> + gpioe-qspi0 - comprises PAD_GPIO_C5 through PAD_GPIO_C11.
> + gpioe-qspi1 - comprises PAD_GPIO_C12 through PAD_GPIO_C19.
> + gpioe-qspi2 - comprises PAD_GPIO_C20 through PAD_GPIO_C27.
> +
> + Each of the above IO groups must be configured with a voltage setting that matches the external
> + voltage level provided to the IO group.
So your hardware has groups and support some properties on the group level.
So expose these groups and make these properties configurable per group
instead of inventing per-group properties.
> + gpioe-spi-vref:
> + gpioe-qspi0-vref:
> + gpioe-qspi1-vref:
> + gpioe-qspi2-vref:
Create proper groups in the pin controller then use the
standard pincfg property power-source = <...>; for this.
Example for a simple default hog:
pinctrl {
/* Hog the QSPI pins */
pinctrl-names = "default";
pinctrl-0 = <&qspi_default>;
qspi_default: pinctrl-qspi {
config {
groups = "gpioe-qspi-pins";
power-source = <2>;
};
};
};
The groups can be orthogonal to other pin handling, that's
fine. Implement .pin_config_group_set in struct pinconf_ops.
However, I found that pinctrl_generic_pins_function_dt_node_to_map() does not
handle the groups property, currently, my node uses pins instead, so it looks like this:
+&pinctrl_per3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gpios_configs>;
+
+ gpios_configs: gpios-hog-grp {
+ gpios-hog-pins {
+ pins = <PADNUM_PER3_GPIO_E0
+ PADNUM_PER3_GPIO_E1
+ PADNUM_PER3_GPIO_E2
+ PADNUM_PER3_GPIO_E3
+ PADNUM_PER3_GPIO_E4
+ PADNUM_PER3_GPIO_E5
+ PADNUM_PER3_GPIO_E6
+ PADNUM_PER3_GPIO_E7
+ PADNUM_PER3_GPIO_E8
+ PADNUM_PER3_GPIO_E9
+ PADNUM_PER3_GPIO_E10>;
+ power-source = <JHB100_PINVREF_1_8V>;
+ };
+ };
+};
Best regards,
Changhuang
More information about the linux-riscv
mailing list