linux-kernel - Re: [PATCH 1/4] documentation: add palmas dts definition

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, 28 Feb 2013 11:51:22 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Laxman Dewangan <ldewangan@...dia.com>
CC:	J Keerthy <j-keerthy@...com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"b-cousson@...com" <b-cousson@...com>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>
Subject: Re: [PATCH 1/4] documentation: add palmas dts definition

On 02/28/2013 01:52 AM, Laxman Dewangan wrote:
> On Thursday 28 February 2013 12:02 AM, Stephen Warren wrote:
>> On 02/17/2013 10:11 PM, J Keerthy wrote:
>> +- interrupt-parent : The parent interrupt controller.
>> +
>> +Optional node:
>> +- Child nodes contain in the palmas. The palmas family is made of
>> several
>> +  variants that support a different number of features.
>> +  The child nodes will thus depend of the capability of the variant.
>> Are there DT bindings for those child nodes anywhere?
>>
>> Representing each internal component as a separate DT node feels a
>> little like designing the DT bindings to model the Linux-internal MFD
>> structure. DT bindings should be driven by the HW design and OS-agnostic.
>>
>>  From a DT perspective, is there any need at all to create a separate DT
>> node for each component? This would only be needed or useful if the
>> child IP blocks (and hence DT bindings for those blocks) could be
>> re-used in other top-level devices that aren't represented by this
>> top-level ti,palmas DT binding. Are the HW IP blocks here re-used
>> anywhere, or will they be?
> 
> 
> I dont think that child IP block can be used outside of the palma
> although other mfd device may have same IP.

That sounds like pretty much the definition of re-using the IP block...

> The child driver very much used the palma's API for register access and
> they can not be separated untill driver is write completely independent
> of palmas API. Currently, child driver include the palma header, uses
> palma mfd stcruture and plama's api for accessing registers.

The DT binding and compatible values should not be influenced by
OS-specific driver implementation details. DT bindings are supposed to
be (as near as possible) a pure HW description, which (many different)
OSs parse, and map to their internal driver structure as appropriate.

The above is of course just a comment on how DT is supposed to work; I'm
not saying anything here re: what's the most appropriate DT structure
for this device.

>>> +    palmas_pmic {
>> Just "pmic" seems simpler, although I dare say the node name isn't
>> really used for anything.
> 
> Stephen,
> Just curios, why do we require the palma_pmic node at all, We can start
> with regulator node directly. Is it not too much nested here?

That was the question I was asking in my original email. But I also
commented on the patch as written, in case the answer to my question was
that the child DT nodes made sense.
--
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/