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:	Tue, 25 Oct 2011 12:31:51 +0530
From:	Rajendra Nayak <rnayak@...com>
To:	Shawn Guo <shawn.guo@...escale.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	patches@...aro.org, tony@...mide.com,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	linux-omap@...r.kernel.org, lrg@...com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data

On Tuesday 25 October 2011 12:38 PM, Shawn Guo wrote:
> On Tue, Oct 25, 2011 at 11:40:34AM +0530, Rajendra Nayak wrote:
>> On Monday 24 October 2011 09:21 PM, Shawn Guo wrote:
>>> On Mon, Oct 24, 2011 at 04:56:31PM +0200, Grant Likely wrote:
> [...]
>>>> It is always better to attach the of_node at struct device
>>>> registration time instead of searching the tree in common code.  The
>>>> of_node should already be assigned by the time regulator_register() is
>>>> called.
>>>
>>> That's the problem we have.  There is no 'struct dev' to attach of_node
>>> for each regulator by the time regulator_register() is called, because
>>> the 'struct dev' for each regulator is created inside
>>> regulator_register() as wrapped by 'struct regulator_dev'.
>>
>> The root of your problem seems to be that your pmic driver isn't
>> registering regulator devices from DT, and if it did, you wouldn't
>> need to do a search in dev->parent->of_node and instead the driver
>> would have the right dev->of_node populated.
>>
> No, it's not the root of my problem.  Again, we are talking about
> 'Case 2', where multiple regulator devices are registered to
> regulator core with regulator driver being probed once, where each
> regulator node is taken as the child of 'regulators' node.  Having
> device_node of 'regulators' attached to dev->of_node does not help
> at all.  What we need is to have each child node attached to
> regulator_dev->dev.of_node.

It certainly helps if dev->of_node has the 'regulators' node attached.
The driver can very easily then do a for_each_child_of_node() to extract
and register individual regulators passing an additional of_node param.

>

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