public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Stein <alexander.stein@ew.tq-group.com>
To: andrew@lunn.ch, Yan Wang <rk.code@outlook.com>
Cc: Yan Wang <rk.code@outlook.com>,
	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: Wed, 10 May 2023 13:55:15 +0200	[thread overview]
Message-ID: <9107661.CDJkKcVGEf@steina-w> (raw)
In-Reply-To: <KL1PR01MB54482416A8BE0D80EA27223CE6779@KL1PR01MB5448.apcprd01.prod.exchangelabs.com>

Am Mittwoch, 10. Mai 2023, 10:02:52 CEST schrieb Yan Wang:
> It is possible to mount multiple sub-devices on the mido bus.

mdio bus

> 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.
> 
> So, before adding a reset to the scan, make sure the device is in
> normal working mode.
> 
> 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.
> 
> Signed-off-by: Yan Wang <rk.code@outlook.com>

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]

[1] https://lkml.org/lkml/2020/10/28/1139

> ---
> v2:
>   - fixed commit message
>   - Using gpiod_ replace gpio_
> v1:
> https://lore.kernel.org/all/KL1PR01MB5448631F2D6F71021602117FE6769@KL1PR01M
> B5448.apcprd01.prod.exchangelabs.com/ - Incorrect description of commit
> message.
>   - The gpio-api too old
> ---
>  drivers/net/mdio/fwnode_mdio.c | 16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/net/mdio/fwnode_mdio.c b/drivers/net/mdio/fwnode_mdio.c
> index 1183ef5e203e..6695848b8ef2 100644
> --- 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]);
>  }
> 
> +static void fwnode_mdiobus_pre_enable_phy(struct fwnode_handle *fwnode)
> +{
> +	struct gpio_desc *reset;
> +
> +	reset = fwnode_gpiod_get_index(fwnode, "reset", 0, GPIOD_OUT_HIGH, 
NULL);
> +	if (IS_ERR(reset) && PTR_ERR(reset) != -EPROBE_DEFER)

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?

> +		return;
> +
> +	usleep_range(100, 200);

How do you know a PHY's reset pulse width?

> +	gpiod_set_value_cansleep(reset, 0);

What about post-reset stabilization times before MDIO access is allowed?

> +	/*Release the reset pin,it needs to be registered with the PHY.*/

/* Release [...] PHY. */

Best regards,
Alexander

> +	gpiod_put(reset);
> +}
> +
>  int fwnode_mdiobus_phy_device_register(struct mii_bus *mdio,
>  				       struct phy_device *phy,
>  				       struct fwnode_handle *child, 
u32 addr)
> @@ -119,6 +133,8 @@ int fwnode_mdiobus_register_phy(struct mii_bus *bus,
>  	u32 phy_id;
>  	int rc;
> 
> +	fwnode_mdiobus_pre_enable_phy(child);
> +
>  	psec = fwnode_find_pse_control(child);
>  	if (IS_ERR(psec))
>  		return PTR_ERR(psec);


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/



  reply	other threads:[~2023-05-10 11:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-09 10:44 [PATCH v1] net: mdiobus: Add a function to deassert reset Yan Wang
2023-05-09 12:22 ` Andrew Lunn
2023-05-09 14:27   ` Yan Wang
2023-05-10  8:02   ` [PATCH v2] " Yan Wang
2023-05-10 11:55     ` Alexander Stein [this message]
2023-05-11  3:16       ` Yan Wang
2023-05-12  8:01         ` Alexander Stein

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9107661.CDJkKcVGEf@steina-w \
    --to=alexander.stein@ew.tq-group.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rk.code@outlook.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox