> Ok. I'm fine with moving the phy-reset-gpios binding into the PHY.
> But one question still remains: Who should then trigger the "hard
> reset" of the PHY?
Hi Richard
I think i see a few whys to do this, but first i need to check
something. Is the clock which is causing a problem this one:
/* clk_ref is optional, depends on board */
fep->clk_ref = devm_clk_get(&pdev->dev, "enet_clk_ref");
if (IS_ERR(fep->clk_ref))
fep->clk_ref = NULL;
Possible solutions:
1) clocks are referenced counted. If it is turned on twice, it needs
to be turned off twice before it is actually turned off. So, make
the PHY driver also clk_prepare_enable() this clock. When the FEC
tries to turn it off, it will stay ticking. Problem avoided, at the
expense of some power.
2) More complex, but make the PHY driver also a clock driver. Have the
PHY driver export a clock which the FEC use, as "enet_clk_ref". The
implementation of this clock, would both turn the real clock on,
and the perform the reset.
Both require no changes to the FEC, or any other MAC driver using this
PHY, so long as the MAC driver uses the common clock infrastructure to
control the clock to the PHY.
Andrew
--
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
