Re: [PATCH] mfd: core: introduce of_node_name for mfd sub devices

[Stephen Warren]

On 09/19/2013 02:29 AM, Laxman Dewangan wrote:

> diff --git a/Documentation/devicetree/bindings/mfd/mfd-core.txt b/Documentation/devicetree/bindings/mfd/mfd-core.txt

> +MFD DT binding document
> +-----------------------
> +
> +Multi Function Devices (MFDs) have multiple sub module whose driver is developed
> +in different sub-system like GPIO, regulators, RTC, clock etc. The device
> +tree of such device contains multiple sub-node which contains the properties
> +of these sub-modules.
> +The sub modules get of_node handle either by the dev->of_node or by getting
> +the child node handle from parent DT handle by finding child name on parent's
> +of_node.
> +To provide the of_node of sub-module directly, there is two approach:
> +- Add compatible value when defining the sub-module in mfd core and
> +  add this properties when adding DT.
> +- Add the of_node_name when defining the sub-module in mfd core and
> +  add keep same name of child node when adding DT.
> +
> +If none of above matches then sub-module driver will not get their of_node
> +and they need to derive the method to get their node from parent node.

That's all *far* too specific to Linux's internals for a DT binding
document.

I think it's fine for DT bindings for aggregate devices to be written to
require a separate node (with a specific name) for various
sub-components of the HW, if it makes sense to do so from a purely DT
binding perspective. However, the fact that some DT bindings might be
written that way implies nothing about any other particular DT binding,
nor about all other DT bindings.

And indeed if you find that there are a bunch of DT bindings that share
this structure, by all means create some common code to simplify the
drivers for those bindings. However, that still doesn't mean that every
driver or binding has to be structured like that.
--
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/