On Thursday 19 September 2013 05:52 PM, Lee Jones wrote:
Do the sub-nodes have their own properties? If so, it would be worth
breaking them up as other OSes could reuse the specifics. If they do,
then you need so put them in the binding. If they don't, then you do
not require sub-nodes. The MFD core will ensure the sub-devices are
probed and there is no requirement for the of_node to be assigned.
You do see some reusable IP blocks (like the regualtors on the wm831x
PMICs for example, they're repeated blocks) which can be reused but
generally they have a register base as part of the binding. Personally
if it's just a property or two I'd probably just put them on the root
node for the device.
Agreed. Besides, there doesn't seem to be *any* sub-device properties
defined in the binding document. So what are you trying to achieve
with the child nodes?
I wanted to have the DT like:
as3722 {
compatible = "ams,as3722";
reg = <0x40>;
#interrupt-controller;
.....
regulators {
ldo1-in-supply = <..>;
....
sd0 {
regulator-name = "vdd-cpu";
.....
};
sd1 {
regulator-name = "vdd-ddr";
.....
};
....
};
};
And regulator driver should get the regulator node by their
pdev->dev.of_node.
Currently, in most of driver, we are having the code on regulator
driver to get "regulators" node from parent node which I want to
avoid.
Ah, I see. Yes, I believe the regulators should have their own node,
complete with a compatible string. To have each regulator listed
separately in the parent node seems a little messy. Just out of
interest, how many regulators are we talking about here?
There is 7 DCDC step down and 10 LDOs.
It is more readable if sub-module properties are grouped and defined on
different sub-node in place of having this in single parent node.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
