Re: Implement devicetree support for AB8500 Btemp

[Arnd Bergmann]

On Friday 14 September 2012, Anton Vorontsov wrote:
> Power supply subsystem's supplied_to describes not just how driver
> should notify other devices, supplied_to is more generic stuff, in terms
> that it describes power supply hierarchy. It's like a directed graph,
> e.g.:
> 
>       <AC power> supplied_to <main battery> and <backup battery>
>      <USB power> supplied_to <main battery> and <backup battery>
>   <main battery> supplied_to <system>
> <backup battery> supplied_to <system>
>   <cmos battery> supplied_to <southbridge pci device>
>   <mice battery> supplied_to <mice wireless hid>
> 
> How things interact in linux are just implementations details.
> So, device tree is surely a perfect place to describe these things.
> 
> Although, in current bindings I see this:
> 
> +       ab8500-fg {
> +               /* Other enery management module */
> +               supplied_to = "ab8500_chargalg", "ab8500_usb";
> +               num_supplicants = <2>;
> +       };
> 
> Instead of addressing supplicants by name, it's better to address
> via phandles. And, of course, num_supplicants is not needed, it can
> be derived.

Right. that's what I thought. The other comment I made initially is
that it would be more in the spirit of the existing bindings to have
the supply property in the opposite directory, if we need it, like
(picking up your above example):


/ {
	/* power supply property in the root node is used by default */
	power-supply = <&main-battery>, <&backup-battery>;

	ac-power: power@... {
		...
	};

	usb-power: power@... {
		...
	};

	main-battery: battery@... {
		power-supply = <&ac-power>, <&usb-power};
	;

	...
};

It's the same information and absolutely equivalent as far as I can tell,
but it feel more logical in the way we tend to describe things.

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