On Thu, Mar 17, 2011 at 11:43:34PM -0600, Grant Likely wrote:
On Fri, Mar 18, 2011 at 09:49:17AM +0800, Shawn Guo wrote:
On Thu, Mar 17, 2011 at 10:42:38AM -0600, Grant Likely wrote:
On Wed, Mar 16, 2011 at 11:51:39PM +0800, Jason Liu wrote:
[...]
- aips@83f00000 {
#address-cells = <1>;#size-cells = <1>;compatible = "simple-bus";ranges = <0x0 0x83f00000 0x100000>;fec@ec000 {compatible = "fsl,imx51-fec";reg = <0xec000 0x1000>;interrupts = <0x57>;fec_clk-clock = <&fec_clk>, "fec";Unfortunately we're leaking Linux implementation details here by needing to use the name "fec_clk". This will require some more thought on the best way to handle (but I'm not asking you to change anything yet).
This constraint comes from function of_clk_get in drivers/of/clock.c:
struct clk *of_clk_get(struct device *dev, const char *id) { [...] dev_dbg(dev, "Looking up %s-clock from device tree\n", id);
snprintf(prop_name, 32, "%s-clock", id ? id : "bus"); prop = of_get_property(dev->of_node, prop_name, &sz);[...] }
The 'id' here is clk_lookup->con_id. If we choose to use some fixed prop name here, the name leaking Linux implementation like 'fec_clk' will not need to be there.
What about fixing the name as 'bus-clock' used by the current implementation, or 'module-clock', or anything you can think of better?
Yeah, I though about that, but I'm being very careful about hard coding anything in the core DT code because every platform seems to want something different here, or want a different set of clocks. I don't have a good solution for this yet.
We are not hard coding anything but a property name here. We are hard coding property name everywhere in dt code, aren't we?