linux-kernel - Re: [PATCH V2 6/6] pinctrl: tegra: Add complete device tree support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4F69FCBF.3050708@wwwdotorg.org>
Date:	Wed, 21 Mar 2012 10:07:27 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Dong Aisheng <aisheng.dong@...escale.com>
CC:	"linus.walleij@...aro.org" <linus.walleij@...aro.org>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	Dong Aisheng-B29396 <B29396@...escale.com>,
	"s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
	"dongas86@...il.com" <dongas86@...il.com>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"thomas.abraham@...aro.org" <thomas.abraham@...aro.org>,
	"tony@...mide.com" <tony@...mide.com>,
	"sjg@...omium.org" <sjg@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH V2 6/6] pinctrl: tegra: Add complete device tree support

On 03/21/2012 03:35 AM, Dong Aisheng wrote:
> On Wed, Mar 21, 2012 at 01:44:39AM +0800, Stephen Warren wrote:
>> Implement pinctrl_ops dt_node_to_map() and dt_free_map(). These allow
>> complete specification of the desired pinmux configuration using device
>> tree.
>>
>> Signed-off-by: Stephen Warren <swarren@...dotorg.org>
>> ---
>> v2: Rebase on of_property_for_each_string() API changes.
>> ---
> Nice code and a good example to people.
> 
> A small suggestion below:
>> +static int add_map_configs(struct pinctrl_map **map, unsigned *num_maps,
>> +			   const char *group, unsigned long *configs,
>> +			   unsigned num_configs)
>> +{
>> +	unsigned i = *num_maps;
>> +	unsigned long *dup_configs;
>> +	int ret;
>> +
>> +	dup_configs = kmemdup(configs, num_configs * sizeof(*dup_configs),
>> +			      GFP_KERNEL);
>> +	if (!dup_configs)
>> +		return -ENOMEM;
>> +
>> +	ret = add_map(map, num_maps);
>> +	if (ret < 0)
>> +		return ret;
>> +
>> +	(*map)[i].type = PIN_MAP_TYPE_CONFIGS_GROUP;
>
> It still does not support PIN_MAP_TYPE_CONFIGS_PIN, right?

Yes.

This is mainly due to a pinctrl core limitation. The core only supports
muxing on groups, so even though the Tegra30 HW supports muxing per pin,
the driver must define a group for each pin. Given that, it's simplest
just to do all the pin config on those same groups.

If/when the pinctrl core supports muxing per pin, we can take advantage
of this within the Tegra pinctrl driver without affecting the binding at
all.

>> +	for_each_child_of_node(np_config, np) {
>> +		ret = of_property_read_string(np, "nvidia,function", &function);
>> +		if (ret < 0)
>> +			function = NULL;
>> +
>> +		for (i = 0; i < ARRAY_SIZE(cfg_params); i++) {
>> +			ret = of_property_read_u32(np, cfg_params[i].property,
>> +						   &val);
>> +			if (!ret) {
>> +				config = TEGRA_PINCONF_PACK(
>> +						cfg_params[i].param, val);
>> +				ret = add_config(&configs, &num_configs,
>> +						 config);
>> +				if (ret < 0)
>> +					goto error;
>> +			}
>> +		}
>> +
>> +		of_property_for_each_string(np, "nvidia,pins", prop, group) {
>
> If we calculate out the strings count and allocate corresponding size array, we may not
> need to keep krealloc the maps and configs array size for each entry.
> And this may be a little higher efficient.

That's true. However, it'd require the code to loop once to determine
how many properties are present and how many entries there are in the
pin list. Then, loop again to actually construct the mapping table
array. This is all added complexity that doesn't affect correctness. I'd
rather get the simple code going first, and then refine it later if
there turns out to be a performance issue.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/