[RFC] regulator: da9052/53: da9052-i2c.txt binding document changes

[RFC] regulator: da9052/53: da9052-i2c.txt binding document changes

[Steve Twiss]

Hi,

The binding file for DA9052/53 exists in the kernel and was originally
submitted by Ying-Chun Liu from Linaro way back in 2012.

Documentation/devicetree/bindings/mfd/da9052-i2c.txt 
> git show 58d114b

The patch adds support for the Dialog MFD and it lists the compatible strings
"dlg,da9052", "dlg,da9053-aa", etc. in the driver code. But, it also lists
some regulator binding names for the two chips DA9052 and DA9053. These
regulator names are added to the binding document but not used in the driver,
also they are named incorrectly compared to the datasheets and Linux driver,
and are misleading and confusing.

+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9052/53 regulators are
+  bound using their names as listed below:
+
+    buck0     : regulator BUCK0
+    buck1     : regulator BUCK1
+    buck2     : regulator BUCK2
+    buck3     : regulator BUCK3
+    ldo4      : regulator LDO4
+    ldo5      : regulator LDO5
+    ldo6      : regulator LDO6
+    ldo7      : regulator LDO7
+    ldo8      : regulator LDO8
+    ldo9      : regulator LDO9
+    ldo10     : regulator LDO10
+    ldo11     : regulator LDO11
+    ldo12     : regulator LDO12
+    ldo13     : regulator LDO13


For example: 
 - ldo10 in this binding list is LDO7 in the driver and in our datasheet
 - ldo7  in this binding list is LDO4 in the driver and in our datasheet

The main problem, and my request for comment is this:

I understand these are supposed to be the definitive definitions, but they
are at best, confusing. They are also not used. I would like to support the
proper names for the regulators.

The easiest solution for me would be to delete the binding file and create a
new one with the correct bindings. But I am guessing this is probably
unacceptable? Is it?

diff --git a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt b/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
deleted file mode 100644
index 1857f4a..0000000
--- a/Documentation/devicetree/bindings/mfd/da9052-i2c.txt
+++ /dev/null
@@ -1,60 +0,0 @@
[... etc]

If not acceptable to anybody but me, then, a second option might be to support
two binding names at once, 'forget' the incorrect ones in the binding
documents, and implement two names in the driver code and make it backwards
compatible that way.

Because the names are interchangeable between datasheets/code and bindings,
ldo10 <-> ldo7 <-> ldo4, this is not quite possible, so I would need to rename
the new bindings to be something like "ldo_7" instead of "ldo7".

Are there any precedents for these sorts of change in the past?

I would really like to use the "ldo7" naming convention style instead of the
"ldo_7" (underscore style) because that matches up with our datasheets and the
Linux driver code, and all of our other regulator drivers currently in the
kernel, DA9062, D9063, etc. Therefore erasing the old regulator bindings would
be the best option for me.

Regards,
Steve

RE: [RFC] regulator: da9052/53: da9052-i2c.txt binding document changes

[Steve Twiss]

On 22 July 2016 11:36, Steve Twiss wrote:

> The binding file for DA9052/53 exists in the kernel and was originally
> submitted by Ying-Chun Liu from Linaro way back in 2012.
[...]
> > git show 58d114b
 [...]
> regulator names are added to the binding document but not used in the driver,
> also they are named incorrectly compared to the datasheets and Linux driver,
> and are misleading and confusing.
> 
> +Sub-nodes:
> +- regulators : Contain the regulator nodes. The DA9052/53 regulators are
> +  bound using their names as listed below:
> +
> +    buck0     : regulator BUCK0
> +    buck1     : regulator BUCK1
> +    buck2     : regulator BUCK2
> +    buck3     : regulator BUCK3
> +    ldo4      : regulator LDO4
> +    ldo5      : regulator LDO5
> +    ldo6      : regulator LDO6
> +    ldo7      : regulator LDO7
> +    ldo8      : regulator LDO8
> +    ldo9      : regulator LDO9
> +    ldo10     : regulator LDO10
> +    ldo11     : regulator LDO11
> +    ldo12     : regulator LDO12
> +    ldo13     : regulator LDO13

Never mind, I guess this is solved now.

There are already several device tree files using a naming scheme different to that found
in the binding text document. Since those have been used for real already, I will just follow
those existing DT file naming conventions instead.

./arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
./arch/arm/boot/dts/imx53-qsb.dts

Those board files files use the naming convention:
{ buck1, buck2, buck3, buck4 }
{ ldo1, ldo2, ldo3, ldo4, ldo5, ldo6, ldo7, ldo8, ldo9, ldo10 }

So, instead of the naming convention used in the existing binding text file (listed above)
I will send a patch to update that file to use with the existing usage already found in the
kernel board files.

Regards,
Steve

Re: [RFC] regulator: da9052/53: da9052-i2c.txt binding document changes

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Mon, Jul 25, 2016 at 11:31:27AM +0000, Steve Twiss wrote:

> There are already several device tree files using a naming scheme different to that found
> in the binding text document. Since those have been used for real already, I will just follow
> those existing DT file naming conventions instead.

The other thing you can try to do here is have a -v2 binding with the
corrected names that's easier for people to follow though it does make
the implementation more complex and may not be worth it.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

RE: [RFC] regulator: da9052/53: da9052-i2c.txt binding document changes

[Steve Twiss]

On 27 July 2016 19:24, Mark Brown wrote:

> On Mon, Jul 25, 2016 at 11:31:27AM +0000, Steve Twiss wrote:
> 
> > There are already several device tree files using a naming scheme different to that found
> > in the binding text document. Since those have been used for real already, I will just follow
> > those existing DT file naming conventions instead.
> 
> The other thing you can try to do here is have a -v2 binding with the
> corrected names that's easier for people to follow though it does make
> the implementation more complex and may not be worth it.

Yes, I think it would be overly complicated to have a -v2 compatible option in this case.