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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 23 Aug 2012 22:31:01 +0200
From:	Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
To:	Stephen Warren <swarren@...dotorg.org>
CC:	Thomas Petazzoni <thomas.petazzoni@...e-electrons.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Rob Landley <rob@...dley.net>,
	Russell King <linux@....linux.org.uk>,
	Lior Amsalem <alior@...vell.com>, Andrew Lunn <andrew@...n.ch>,
	Gregory CLEMENT <gregory.clement@...e-electrons.com>,
	Ben Dooks <ben.dooks@...ethink.co.uk>,
	Linus Walleij <linus.walleij@...aro.org>,
	devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 1/9] pinctrl: mvebu: pinctrl driver core

On 08/23/2012 07:54 PM, Stephen Warren wrote:
>> dt_parse() and dt_parse_function() build up structs that get used later on
>> in mvebu_pinmux_ops that require indexed functions. I can join them with
>> dt_node_to_map() but that would require incremental kzalloc for the
>> corresponding array. Or I could (functionally) leave dt_parse() to allocate
>> the array and only join dt_parse_function() with dt_node_to_map().
>
> So everything you said makes sense, in that the core driver is
> parameterizable and receives data from a SoC-variant-specific driver
> indicating which pins/groups/functions are available. I'm still not sure
> though why the translation of the pin/group/function structures passed
> to probe into other data structures requires accessing the DT at all;
> the set of available pins/groups/functions isn't configured through DT,
> and doesn't need to be limited to only those options actually used in
> DT, so can't you just process all the data that's passed to probe
> without interaction with the DT?

Hmm, maybe I still don't quite understand the terminology of pinctrl/pinmux
core completely. What exactly should mvebu_pinmux_get_funcs_count return
if not the number of DT node children?

I thought that a "function" in the terminology of pinctrl/pinmux core is
a list of pingroups and corresponding values to actually set it to e.g. uart1.
In pinctrl-mvebu this would be one marvell,function assigned to one or more
marvell,pins.

If the above is correct, I still need to access DT in probe() at least to count
the number of children passed to allocate an array for mvebu_pinmux_ops callbacks
that get indexed by "fid" (pctl->functions).

Sebastian
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ