On Mon, Dec 11, 2017 at 01:16:57PM +0100, Richard Leitner wrote:
> From: Richard Leitner <richard.leit...@skidata.com>
> 
> Some PHYs need a minimum time after the reset gpio was asserted and/or
> deasserted. To ensure we meet these timing requirements add two new
> optional devicetree parameters for the phy: reset-delay-us and
> reset-post-delay-us.
> 
> Signed-off-by: Richard Leitner <richard.leit...@skidata.com>
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> ---
>  Documentation/devicetree/bindings/net/phy.txt | 10 ++++++++++
>  drivers/net/phy/mdio_device.c                 | 13 +++++++++++--
>  drivers/of/of_mdio.c                          |  4 ++++
>  include/linux/mdio.h                          |  2 ++
>  4 files changed, 27 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/net/phy.txt 
> b/Documentation/devicetree/bindings/net/phy.txt
> index c05479f5ac7c..72860ce7f610 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -55,6 +55,12 @@ Optional Properties:
>  
>  - reset-gpios: The GPIO phandle and specifier for the PHY reset signal.
>  
> +- reset-delay-us: Delay after the reset was asserted in microseconds.
> +  If this property is missing the delay will be skipped.
> +
> +- reset-post-delay-us: Delay after the reset was deasserted in microseconds.
> +  If this property is missing the delay will be skipped.

I think these names could be clearer as to exactly what they mean. 
Looking at existing properties with "reset-delay" there's a mixture of 
definitions whether it is the assert time or the time after deassert.

So I'd call these "reset-assert-us" and "reset-deassert-us".

Rob

Reply via email to