linux-kernel - Re: [Patch v3 3/4] power_supply: tps65090-charger: Add binding doc

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]

Message-ID: <513FB5D7.5090800@wwwdotorg.org>
Date:	Tue, 12 Mar 2013 17:10:15 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Rhyland Klein <rklein@...dia.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...xeda.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Anton Vorontsov <cbou@...l.ru>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	linux-tegra@...r.kernel.org, linux-kernel@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org,
	Laxman Dewangan <ldewangan@...dia.com>
Subject: Re: [Patch v3 3/4] power_supply: tps65090-charger: Add binding doc

On 03/12/2013 04:08 PM, Rhyland Klein wrote:
> This change adds the binding documentation for the tps65090-charger.

> diff --git a/Documentation/devicetree/bindings/power_supply/tps65090.txt b/Documentation/devicetree/bindings/power_supply/tps65090.txt

> +Example:
> +
> +	tps65090@48 {
> +		compatible = "ti,tps65090";
> +		reg = <0x48>;
> +		interrupts = <0 88 0x4>;
> +
> +		ti,enable-low-current-chrg;
> +
> +		regulators {
> +			...
> +		};

I'm a little confused by this binding.

What goes in the regulators sub-node; is that specified by another
binding file in bindings/regulator/tps65090.txt?

I would expect one of the following:

1) A single binding file that describes absolutely everything in the
chip. In this case, the main TPS65909 node wouldn't have child nodes for
the MFD components, although the regulators sub-node, which in turn
contains children does still make sense.

2) A separate binding for each component block, and perhaps also some
top-level binding that indicates which child bindings can "plug into"
it. In this case, I'd expect each block to be represented as a sub-node
in DT. The overall regulator component might then still have a
regulators child DT node itself, to represent each regulator's
configuration. In this scenario, each binding document describes the
entirety of a single node.

I think what you've got here is a hybrid; a single top-level node, but
different binding documents defining the various properties that are
relevant to each component block in the device. That seems odd to me.
--
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/