On Mon, Dec 18, 2017 at 1:30 AM, Richard Leitner <richard.leit...@skidata.com> wrote: > Hi Rob, > > On 12/15/2017 11:17 PM, Rob Herring wrote: >> 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". > > Ok, that would be fine with me, but are you sure that we should omit the > "-delay" term completely?
These are just minimum assertion and deassertion times. I think that's clear enough. > What would be the best approach to post this change (as the patchset was > already merged to net-next)? A separate patch or a v6 of the complete > patchset? A patch on top of this. Rob
