net: fec: Add "phy-reset-active-low" property to DT
Subsystems (3)
We need that for a custom hardware that needs the reverse reset sequence.
--- Documentation/devicetree/bindings/net/fsl-fec.txt | 3 +++ drivers/net/ethernet/freescale/fec_main.c | 8 ++++++-- 2 files changed, 9 insertions(+), 2 deletions(-)
(quoted diff) +0 -0
b/Documentation/devicetree/bindings/net/fsl-fec.txt index a9eb611..a4799ff 100644
Documentation/devicetree/bindings/net/fsl-fec.txt +3 -0
@@ -12,6 +12,9 @@ Optional properties: only if property "phy-reset-gpios" is available. Missing the property will have the duration be 1 millisecond. Numbers greater than 1000 are invalid and 1 millisecond will be used instead. +- phy-reset-active-low : If present then the reset sequence using the GPIO + specified in the "phy-reset-gpios" property is reversed (H=reset state, + L=operation state).
____________________________
Shouldn't this be named phy-reset-active-high, as you are making the reset active high H=reset, L= normal operation
Troy
Hi,
sorry for my late reply.
Quoted 9 lines · Troy Kisky
invalid and 1 millisecond will be used instead.
+- phy-reset-active-low : If present then the reset sequence using the GPIODocumentation/devicetree/bindings/net/fsl-fec.txt +2
-0+ specified in the "phy-reset-gpios" property is reversed (H=reset state, + L=operation state).____________________________
Shouldn't this be named phy-reset-active-high, as you are making the reset active high H=reset, L= normal operation
Indeed, you're correct.
Should I send a new patch or a patch that corrects my first patch? Because it already is in linux-next.
Regards,
Bernhard
Quoted 4 lines · Bernhard Walle
Indeed, you're correct.
Should I send a new patch or a patch that corrects my first patch? Because it already is in linux-next.
As your patch is already in linux-next you should send an incremental patch then. Thanks