From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ramon Fried <rfried.dev@gmail.com>
Date: Thu, 15 Apr 2021 04:41:25 +0300
Subject: [PATCH] net: dwc_eth_qos: add support of device tree
 configuration for reset delay
In-Reply-To: <5deab9a1-3326-5115-71e2-569aa4077ab6@denx.de>
References: <20210409100022.1.I93dea8b89ea632e7d8f2640a6eca6f6e69fed319@changeid>
 <bf1fcbd0-b54e-b03f-1ac2-27475ee747e2@denx.de>
 <68133a1e-5440-0a5d-d5a4-2c1d85ef0c1b@foss.st.com>
 <5deab9a1-3326-5115-71e2-569aa4077ab6@denx.de>
Message-ID: <CAGi-RU+QZRQ8EVPfX7XZET2LodgrU5mkYG+scWNzow9aLFPFEA@mail.gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Wed, Apr 14, 2021 at 5:36 PM Marek Vasut <marex@denx.de> wrote:
>
> On 4/14/21 4:07 PM, Patrick DELAUNAY wrote:
> > Hi,
>
> Hi,
>
> > On 4/9/21 2:22 PM, Marek Vasut wrote:
> >> On 4/9/21 10:00 AM, Patrick Delaunay wrote:
> >>> The gpio reset assert/deassert delay are today harcoded in U-Boot driver
> >>> but the value should be read from DT.
> >>>
> >>> STM32 use the generic binding defined in linux:
> >>> Documentation/devicetree/bindings/net/ethernet-phy.yaml
> >>>
> >>>    reset-gpios:
> >>>      maxItems: 1
> >>>      description:
> >>>        The GPIO phandle and specifier for the PHY reset signal.
> >>>
> >>>    reset-assert-us:
> >>>      description:
> >>>        Delay after the reset was asserted in microseconds. If this
> >>>        property is missing the delay will be skipped.
> >>>
> >>>    reset-deassert-us:
> >>>      description:
> >>>        Delay after the reset was deasserted in microseconds. If
> >>>        this property is missing the delay will be skipped.
> >>>
> >>> See also U-Boot: doc/device-tree-bindings/net/phy.txt
> >>
> >> Since this is a PHY property, shouldn't that be handled in
> >> drivers/net/phy/ instead of MAC driver ?
> >
> >
> > I was my first idea but I don't found found the correct location in phy
> > (driver or uclass)
> >
> > to manage these generic property and the generic property "reset-gpios"
> > was already
> >
> > managed in eth driver, so I continue to patch the driver.
> >
> >
> > But I come back to this idea after your remark....
> >
> > => in linux these property are managed in
> >
> >      drivers/net/mdio/of_mdio.c::of_mdiobus_phy_device_register
> >
> >          parse DT node and add info in mdio
> >
> >      drivers/net/phy/mdio_device.c::mdio_device_reset
> >
> >          called in  mdio_probe / mdio_remove
> >
> >
> > In my first search, I don't found the same level in the U-Boot drivers
> > in drivers/net/phy/
>
> Note that this is MDIO-wide PHY reset (e.g. you can have single reset
> line connected to multiple PHYs on single MDIO bus), this is not
> PHY-specific reset.
>
> > but I miss the uclass defined in drivers/net/eth-phy-uclass.c
> >
> >
> > Finally I think I need to manage the generic binding property
> >
> > (reset-gpios, reset-assert-us, reset-deassert-us) directly  in
> >
> > => drivers/net/mdio-uclass
> >
> >
> > The GPIO RESET will be managed in mdio  ops: pre_probe/ post_remove
> >
> > as it is done in linux
> >
> > warning: today post_remove ops don't exit in u-class.
> >
> >
> > Do you think it is the correct location ?
>
> For single-PHY reset, the correct location is in drivers/net/phy/ somewhere.
>
> > Do you think it should be a new serie (migrate the eqos property in mdio)
> >
> > after this eqos is accepted
> >
> > or I shoudl sent a new serie to replace this serie.
>
> I'll leave that decision to Ramon/Joe.
Joe, I'll leave this to you.