On December 14, 2015 2:56:34 PM PST, Rob Herring <r...@kernel.org> wrote: >On Fri, Dec 11, 2015 at 11:34:53AM +0100, Gregory CLEMENT wrote: >> With device tree it is no more possible to reset the PHY at board >> level. Furthermore, doing in the driver allow to power down the PHY >when >> the network interface is no more used. >> >> This reset can't be done at the PHY driver level. The PHY must be >able to >> answer the to the mii bus scan to let the kernel creating a PHY >device. >> >> The patch introduces a new optional property "phy-reset-gpios" >inspired >> from the one use for the FEC. >> >> Signed-off-by: Gregory CLEMENT <gregory.clem...@free-electrons.com> >> --- >> >> Since the v1, I used the gpiod functions. It allows to simplify the >> code and to not introduce any #ifdef. >> >> I also rename the property in phy-reset-gpios, even if actually the >> gpiod will match both phy-reset-gpios and phy-reset-gpio. >> >> >> Documentation/devicetree/bindings/net/macb.txt | 3 +++ >> drivers/net/ethernet/cadence/macb.c | 8 ++++++++ >> drivers/net/ethernet/cadence/macb.h | 1 + >> 3 files changed, 12 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/net/macb.txt >b/Documentation/devicetree/bindings/net/macb.txt >> index b5d7976..4a7fb6c 100644 >> --- a/Documentation/devicetree/bindings/net/macb.txt >> +++ b/Documentation/devicetree/bindings/net/macb.txt >> @@ -19,6 +19,9 @@ Required properties: >> Optional elements: 'tx_clk' >> - clocks: Phandles to input clocks. >> >> +Optional properties: >> +- phy-reset-gpios : Should specify the gpio for phy reset >> + > >This alone is simple enough, but I worry that this doesn't really >scale. >What if you need to enable clocks or regulators for the same reason? >The >mmc folks did a pwrseq binding for similar reasons. I don't think I'd >recommend that here as I think it is kind of ugly. We really need a >pre-probe/scan hook for drivers. This is also needed for USB devices >mounted on boards.
In this particular case, the way Ethernet MAC drivers register their MDIO buses and therefore PHYs, there is always a good way to deassert the PHY GPIO line without requiring major core device driver changes. Worst case, there is the MDIO bus reset callback which could used for that matter. In the case of PCI, USB etc. I do agree having a way to twiddle things before scanning/probing would be awesome. I have some boards here which have GPIO controlled regulator and hacking the RC driver to deal with that is suboptimal... > >But I'm not going to hold up something simple to do all that, so: > >Acked-by: Rob Herring <r...@kernel.org> > >_______________________________________________ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
