Hello Wenyou, [snip] >> > >> > If then device is not being loaded from the DT (and it shouldn't be, >> > the device looks like it should be instantiated directly by the MFD as >> > it can't exist separately to that MFD) an OF table will do nothing. >> >> Then he should remove the .of_compatible from the MFD cell definition. > > I tried it, > > But if removed this .of_compatible, and reserved the OF table. What we said is that you should remove both the mfd cell .of_compatible field and the OF table. Of course removing one but leaving the other is not correct. > the &pdev->dev->of_node is NULL, the driver fails to get the configuration value from DT, > I see, you mean that you are not able to lookup the "active-semi,vsel-high" property. > It seems the OF table still doesn't work. Where is wrong? > I think the problem is with your DT binding. You have a PMIC dev node with compatible "active-semi,act8945a" that has a child node with compatible "active-semi,act8945a-regulator" which in turn has the "regulators" node. I believe what Mark says is that there shouldn't be a compatible and node for the regulators IC since is part of the PMIC. IOW, you can't have it as a standalone node in the DTS. > Could you help give some suggestion? > I would just remove the "active-semi,act8945a-regulator" node and make "active-semi,vsel-high" a property of the "active-semi,act8945a" node. That way you can remove the mfd cell .of_compatible and OF table in the regulator driver and read the "active-semi,vsel-high" using the platform device's parent of_node. But it's better if you wait for Mark's opinions before re-spining your patches. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
