Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Alexander Stein <alexander.stein@ew.tq-group.com>
To:     andrew@lunn.ch, Yan Wang <rk.code@outlook.com>
Cc:     Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        "open list:ETHERNET PHY LIBRARY" <netdev@vger.kernel.org>,
        open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2] net: mdiobus: Add a function to deassert reset
Date:   Fri, 12 May 2023 10:01:41 +0200
Message-ID: <2561676.Lt9SDvczpP@steina-w>
Organization: TQ-Systems GmbH
In-Reply-To: <KL1PR01MB54486E8738DC81E062BA2D0EE6749@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>
References: <96a1b95e-d05e-40f0-ada9-1956f43010e0@lunn.ch> <9107661.CDJkKcVGEf@steina-w> <KL1PR01MB54486E8738DC81E062BA2D0EE6749@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
Precedence: bulk

Am Donnerstag, 11. Mai 2023, 05:16:52 CEST schrieb Yan Wang:
> On 5/10/2023 7:55 PM, Alexander Stein wrote:
> > Am Mittwoch, 10. Mai 2023, 10:02:52 CEST schrieb Yan Wang:
> >> It is possible to mount multiple sub-devices on the mido bus.
> >=20
> > mdio bus
>=20
> Yes, misspelled.
>=20
> >> The hardware power-on does not necessarily reset these devices.
> >> The device may be in an uncertain state, causing the device's ID
> >> to be scanned.
> >>=20
> >> So, before adding a reset to the scan, make sure the device is in
> >> normal working mode.
> >>=20
> >> I found that the subsequent drive registers the reset pin into the
> >> structure of the sub-device to prevent conflicts, so release the
> >> reset pin.
> >>=20
> >> Signed-off-by: Yan Wang <rk.code@outlook.com>
> >=20
> > We had similar cases where the (single) PHY was in reset during Linux
> > boot.
> > Should you be able to make this work by using a "ethernet-phy-id%4x.%4x"
> > compatible? See also [1]
> >=20
> > [1] https://lkml.org/lkml/2020/10/28/1139
>=20
> Well, I've seen the [1] before, this method may mask some issues. For
> example ,if I use
> another type of phy ,I have to modify the DT, Is it very cumbersome?

You have to change the reset timings and possibly other properties as well =
if=20
you change the PHY, so a DT change is necessary anyway.

Regards,
Alexander

>=20
> >> ---
> >>=20
> >> v2:
> >>    - fixed commit message
> >>    - Using gpiod_ replace gpio_
> >>=20
> >> v1:
> >> https://lore.kernel.org/all/KL1PR01MB5448631F2D6F71021602117FE6769@KL1=
PR0
> >> 1M
> >> B5448.apcprd01.prod.exchangelabs.com/ - Incorrect description of commit
> >> message.
> >>=20
> >>    - The gpio-api too old
> >>=20
> >> ---
> >>=20
> >>   drivers/net/mdio/fwnode_mdio.c | 16 ++++++++++++++++
> >>   1 file changed, 16 insertions(+)
> >>=20
> >> diff --git a/drivers/net/mdio/fwnode_mdio.c
> >> b/drivers/net/mdio/fwnode_mdio.c index 1183ef5e203e..6695848b8ef2 1006=
44
> >> --- a/drivers/net/mdio/fwnode_mdio.c
> >> +++ b/drivers/net/mdio/fwnode_mdio.c
> >> @@ -57,6 +57,20 @@ fwnode_find_mii_timestamper(struct fwnode_handle
> >> *fwnode) return register_mii_timestamper(arg.np, arg.args[0]);
> >>=20
> >>   }
> >>=20
> >> +static void fwnode_mdiobus_pre_enable_phy(struct fwnode_handle *fwnod=
e)
> >> +{
> >> +	struct gpio_desc *reset;
> >> +
> >> +	reset =3D fwnode_gpiod_get_index(fwnode, "reset", 0, GPIOD_OUT_HIGH,
> >=20
> > NULL);
> >=20
> >> +	if (IS_ERR(reset) && PTR_ERR(reset) !=3D -EPROBE_DEFER)
> >=20
> > How are you dealing with EPROBE_DEFER if the reset line is e.g. attached
> > to an i2c expander, which is to be probed later on?
>=20
> Thank you ,The logic is wrong,trying to fix it.
>=20
> >> +		return;
> >> +
> >> +	usleep_range(100, 200);
> >=20
> > How do you know a PHY's reset pulse width?
> >=20
> >> +	gpiod_set_value_cansleep(reset, 0);
> >=20
> > What about post-reset stabilization times before MDIO access is allowed?
>=20
> yes,I need to get reset pulse width and post-reset stabilization times
> from reset-assert-us and  reset-deassert-us. right?
>=20
> >> +	/*Release the reset pin,it needs to be registered with the PHY.*/
> >=20
> > /* Release [...] PHY. */
> >=20
> > Best regards,
> > Alexander
>=20
> Thank you for your support.
>=20
> >> +	gpiod_put(reset);
> >> +}
> >> +
> >>=20
> >>   int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
> >>  =20
> >>   				       struct phy_device *phy,
> >>   				       struct fwnode_handle *child,
> >=20
> > u32 addr)
> >=20
> >> @@ -119,6 +133,8 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bu=
s,
> >>=20
> >>   	u32 phy_id;
> >>   	int rc;
> >>=20
> >> +	fwnode_mdiobus_pre_enable_phy(child);
> >> +
> >>=20
> >>   	psec =3D fwnode_find_pse_control(child);
> >>   	if (IS_ERR(psec))
> >>   =09
> >>   		return PTR_ERR(psec);


=2D-=20
TQ-Systems GmbH | M=FChlstra=DFe 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht M=FCnchen, HRB 105018
Gesch=E4ftsf=FChrer: Detlef Schneider, R=FCdiger Stahl, Stefan Schneider
http://www.tq-group.com/