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:	Mon, 10 Jun 2013 10:21:16 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Benoit Cousson <b-cousson@...com>
CC:	"J, KEERTHY" <j-keerthy@...com>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"ldewangan@...dia.com" <ldewangan@...dia.com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"swarren@...dia.com" <swarren@...dia.com>,
	"sameo@...ux.intel.com" <sameo@...ux.intel.com>,
	"gg@...mlogic.co.uk" <gg@...mlogic.co.uk>,
	"lee.jones@...aro.org" <lee.jones@...aro.org>
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas

On 06/10/2013 03:29 AM, Benoit Cousson wrote:
> Hi Keerthy,
> 
> On 06/10/2013 06:03 AM, J, KEERTHY wrote:
>> Hi Stephen,
>>
>> Thanks for the review comments.
>>
>> ________________________________________
>> From: Stephen Warren [swarren@...dotorg.org]
>> Sent: Saturday, June 08, 2013 1:26 AM
>> To: J, KEERTHY
>> Cc: Cousson, Benoit; devicetree-discuss@...ts.ozlabs.org; linux-omap@...r.kernel.org; linux-kernel@...r.kernel.org; ldewangan@...dia.com; grant.likely@...retlab.ca; swarren@...dia.com; sameo@...ux.intel.com; gg@...mlogic.co.uk; lee.jones@...aro.org
>> Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
>>
>> On 06/07/2013 05:28 AM, J Keerthy wrote:
>>> Adds palmas mfd and palmas regulator nodes. This is
>>> based on the patch series:
>>>
>>> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
>>>
>>> The device tree nodes are based on:
>>> https://lkml.org/lkml/2013/6/6/25
>>
>>> diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
>>
>>> +&palmas {
>>
>> Hmmm. That (i.e. requiring the board file to declare the node, then
>> setting up all the content by later including this file) is an
>> interesting approach. I guess it's reasonable. The one issue is that it
>> makes it a little harder for the board file to override any of the
>> properties in this file., although it certainly is possible by including
>> those overrides after the include.
>>
>> Irrespective of that, some comments on this:
>>
>>> +     palmas_pmic {
>>
>>> +             ti,ldo6-vibrator;
>>
>> For example, what if the board doesn't want to have the property set?
>>
>>> +
>>> +             regulators {
>>> +                     smps123_reg: smps123 {
>>> +                             regulator-name = "smps123";
>>> +                             regulator-min-microvolt = < 600000>;
>>> +                             regulator-max-microvolt = <1500000>;
>>
>> Or what if the board wants to limit the voltage range of this regulator
>> due to what it's used for on the board.
>>
>>> +                             regulator-always-on;
>>> +                             regulator-boot-on;
>>
>> And those two properties are almost certainly board-specific policy.
>>
>> Totally agree to all the above concerns. So can we have a custom .dtsi file
>> for a board+pmic combination? Or have only the required properties over ridden
>> in the board file?
> 
> Yes, you can do that potentially if most OMAP5 boards will reuse the
> same kind of settings. Kevin has just done that for OMAP3 + twl4030.
> 
> In this case, since we do have only one board, I'm not sure it worth the
> effort.

IIUC, various Tegra boards use this PMIC, so there's more than one board
in question here.

Or were you talking about e.g.:

palmas.dtsi          - base Palmas DT node for everything
omapXXXX-palmas.dtsi - common Palmas settings for all OMAP boards

... where the latter file would only be used by one board? If so, then
yes, creating the latter file might not make sense yet.

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