[PATCH v4 3/9] pinctrl: single: support pinconf generic

Tony Lindgren tony at atomide.com
Wed Nov 7 19:25:05 EST 2012


Hi,

* Haojian Zhuang <haojian.zhuang at gmail.com> [121107 07:21]:
> diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
> index a7c5fdd..77aec05 100644
> --- a/drivers/pinctrl/pinctrl-single.c
> +++ b/drivers/pinctrl/pinctrl-single.c
>  static int pcs_pinconf_get(struct pinctrl_dev *pctldev,
>  				unsigned pin, unsigned long *config)
>  {
> +	struct pcs_device *pcs = pinctrl_dev_get_drvdata(pctldev);
> +	enum pin_config_param param = pinconf_to_config_param(*config);
> +	unsigned data;
> +	u32 offset;

Do you need a check here (and also in other pinconf related functions)
for driver instances that don't have pinconf enabled?

Something like:

	if (!pcs->pinconf)
		return -ENOTSUPP;
...


> @@ -806,34 +1000,27 @@ static int pcs_dt_node_to_map(struct pinctrl_dev *pctldev,
>  
>  	pcs = pinctrl_dev_get_drvdata(pctldev);
>  
> -	*map = devm_kzalloc(pcs->dev, sizeof(**map), GFP_KERNEL);
> -	if (!map)
> -		return -ENOMEM;
> +	if (!pcs->conf.nconfs)
> +		*num_maps = 1;
> +	else
> +		*num_maps = 2;
>  
> -	*num_maps = 0;
> +	*map = devm_kzalloc(pcs->dev, sizeof(**map) * (*num_maps), GFP_KERNEL);
> +	if (!*map)
> +		return -ENOMEM;
>  
>  	pgnames = devm_kzalloc(pcs->dev, sizeof(*pgnames), GFP_KERNEL);
> -	if (!pgnames) {
> -		ret = -ENOMEM;
> -		goto free_map;
> -	}
> +	if (!pgnames)
> +		return -ENOMEM;
>  
>  	ret = pcs_parse_one_pinctrl_entry(pcs, np_config, map, pgnames);
>  	if (ret < 0) {
>  		dev_err(pcs->dev, "no pins entries for %s\n",
>  			np_config->name);
> -		goto free_pgnames;
> +		return ret;
>  	}
> -	*num_maps = 1;
>  
>  	return 0;
> -
> -free_pgnames:
> -	devm_kfree(pcs->dev, pgnames);
> -free_map:
> -	devm_kfree(pcs->dev, *map);
> -
> -	return ret;
>  }

Here looks like you're changing the behaviour to not free entries in cases
where parsing with cs_parse_one_pinctrl_entry() fails. I'd prefer the freeing
it in case of parsing errors so we don't waste memory when the system is
running. Also there's a tiny chance that *num_maps will be wrong if the
second devm_kzalloc fails.. But it's more likely that we get a broken device
tree to parse and end up potentially hogging hundreds of maps.

Regards,

Tony



More information about the linux-arm-kernel mailing list