[PATCH 12/20] pinctrl: berlin: add optional pinconf support

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] pinctrl: Unmasked DRIVE_STRENGTH argument corrupts adjacent register bits
- [Medium] pinctrl: memory over-allocation due to incorrect map reservation logic
--

commit 9565e1451acca64670b365c5e1dcc3edb4643737
Author: Jisheng Zhang <jszhang at kernel.org>

pinctrl: berlin: add optional pinconf support

Add pinconf support for newer Synaptics SoCs.

> diff --git a/drivers/pinctrl/berlin/berlin.c b/drivers/pinctrl/berlin/berlin.c
> index 0c2179b986295..06c67f00c5276 100644
> --- a/drivers/pinctrl/berlin/berlin.c
> +++ b/drivers/pinctrl/berlin/berlin.c
[ ... ]
> @@ -75,11 +94,19 @@ static int berlin_pinctrl_dt_node_to_map(struct pinctrl_dev *pctrl_dev,
>  		return -EINVAL;
>  	}
>  
> +	ret = pinconf_generic_parse_dt_config(node, pctrl_dev, &configs,
> +					      &num_configs);
> +	if (ret < 0) {
> +		dev_err(pctrl->dev, "%s: could not parse node property\n",
> +			node->name);
> +		return ret;
> +	}
> +
>  	ret = pinctrl_utils_reserve_map(pctrl_dev, map, &reserved_maps,
> -					num_maps, ngroups);
> +					num_maps, ngroups * (num_configs + 1));

[Severity: Medium]
Does this map reservation logic permanently over-allocate kernel memory for the
lifetime of the parsed pin configuration?

The driver reserves map entries using ngroups * (num_configs + 1). However,
pinctrl_utils_add_map_configs() aggregates the entire array of configurations
into a single map entry. Thus, the driver adds at most 2 entries per group
(one for the mux and one for the configs), regardless of num_configs.

When parsing pin configurations from the device tree where num_configs > 1,
this results in (num_configs - 1) * ngroups unused array elements being
allocated.

>  	if (ret) {
>  		dev_err(pctrl->dev, "can't reserve map: %d\n", ret);
> -		return ret;
> +		goto exit;
>  	}
[ ... ]
> +static int berlin_pinconf_group_set(struct pinctrl_dev *pctrl_dev,
> +				    unsigned int group, unsigned long *configs,
> +				    unsigned int nconfigs)
> +{
[ ... ]
> +		switch (param) {
[ ... ]
> +		case PIN_CONFIG_DRIVE_STRENGTH:
> +			if (conf_bits == 10)
> +				mask |= PINCFG_DS_10BIT;
> +			else
> +				mask |= PINCFG_DS_8BIT;
> +			val |= arg;
> +			break;

[Severity: High]
Can this regression cause the unbounded user-provided arg to overflow and
corrupt adjacent register bits?

When the device tree specifies a drive-strength value that exceeds the unmasked
bit width (e.g., > 15), the parsed arg is added directly to val via val |= arg
without applying a bitmask.

Because val and mask are accumulated across all config parameters in a loop,
the overflowing bits from DRIVE_STRENGTH will be written to the register if
they overlap with the composite mask bits requested by other parameters
(e.g., overriding the PINCFG_IE_10BIT state). This could lead to incorrect
hardware pin states and functional failures on key interfaces during device
probe.

> +		case PIN_CONFIG_INPUT_ENABLE:
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260929061417.20733-1-jszhang@kernel.org?part=12