Re: [PATCH 2/2] ARM: dt: tegra: cardhu: register core regulator tps65911

From: Laxman Dewangan
Date: Tue May 22 2012 - 14:01:47 EST


On Tuesday 22 May 2012 10:49 PM, Stephen Warren wrote:
On 05/22/2012 11:09 AM, Laxman Dewangan wrote:
On Tuesday 22 May 2012 10:10 PM, Stephen Warren wrote:
On 05/22/2012 07:05 AM, Laxman Dewangan wrote:
Add device info for the PMIC device tps65911 in tegra-cardhu
dts file. This device supports the multiple regulator rails,
gpio, interrupts.
FYI, patch 1 in this series looks fine. Some comments below though:

diff --git a/arch/arm/boot/dts/tegra-cardhu.dts
b/arch/arm/boot/dts/tegra-cardhu.dts
+ tps65911: tps65911@2d {
+ compatible = "ti,tps65911";
+ reg =<0x2d>;
+
+ #gpio-cells =<2>;
+ gpio-controller;
+
+ regulators {
Please add the following properties here:

#address-cells =<1>;
#size-cells =<0>;

+ vdd1_reg: vdd1 {
This node name should be "regulator", since nodes are generally named
after the class of object they represent. Since all the nodes will then
have the same name, you'll need to add a unit address ("@nnnn") to the
node name.
Nop, we can not do it. The node name should match with the name
mentioned in driver otherwise the regulator node search will fail
Following is the excerpt of the code:
Hmm. That seems wrong. I thought I had seen at least some regulator
bindings where these nodes included a name property so that the nodes
didn't need any particular name.
It is only applicable for the fixed regulators or the device supports only one regulator or each regulator have their own compatibility and the matching is done by compatibility, not by node name.


Olof, what are your thoughts here - do we need to fix the code so the
node names aren't relevant? IIRC, we have had to change some other
bindings due to the same issue.

...
Nitpicky, but the labels might be more logical as reg_vdd1 rather than
vdd1_reg, but not a big deal.

So, please replace the line above with:

reg_vdd1: regulator@0 {
reg =<0>;

Why do we really require the reg at all?
I dont think any usage of doing this.
I guess if these regulators are enabled at boot and always on, we don't
even need the labels for now; we could add labels later as/when drivers
begin to dynamically control the regulators.

I think we should provide the label here whether it is always on or not.
The driver who uses the rails will not aware that rail is always on or not.
Second thing is that this gives uniformity and whenever any consumer get added, we will not touch this part, only will be change in the driver specific part.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/