From: Maxime Chevallier <maxime.chevallier@bootlin.com>
To: Claudiu <claudiu.beznea@tuxon.dev>
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, yuiko.oshino@microchip.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
Subject: Re: [PATCH net] net: phy: micrel: populate .soft_reset for KSZ9131
Date: Fri, 5 Jan 2024 10:43:23 +0100 [thread overview]
Message-ID: <20240105104323.76ddfdca@device-28.home> (raw)
In-Reply-To: <20240105085242.1471050-1-claudiu.beznea.uj@bp.renesas.com>
Hi Claudiu,
On Fri, 5 Jan 2024 10:52:42 +0200
Claudiu <claudiu.beznea@tuxon.dev> wrote:
> From: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
>
> The RZ/G3S SMARC Module has 2 KSZ9131 PHYs. In this setup, the KSZ9131 PHY
> is used with the ravb Ethernet driver. It has been discovered that when
> bringing the Ethernet interface down/up continuously, e.g., with the
> following sh script:
>
> $ while :; do ifconfig eth0 down; ifconfig eth0 up; done
>
> the link speed and duplex are wrong after interrupting the bring down/up
> operation even though the Ethernet interface is up. To recover from this
> state the following configuration sequence is necessary (executed
> manually):
>
> $ ifconfig eth0 down
> $ ifconfig eth0 up
>
> The behavior has been identified also on the Microchip SAMA7G5-EK board
> which runs the macb driver and uses the same PHY.
>
> The order of PHY-related operations in ravb_open() is as follows:
> ravb_open() ->
> ravb_phy_start() ->
> ravb_phy_init() ->
> of_phy_connect() ->
> phy_connect_direct() ->
> phy_attach_direct() ->
> phy_init_hw() ->
> phydev->drv->soft_reset()
> phydev->drv->config_init()
> phydev->drv->config_intr()
> phy_resume()
> kszphy_resume()
>
> The order of PHY-related operations in ravb_close is as follows:
> ravb_close() ->
> phy_stop() ->
> phy_suspend() ->
> kszphy_suspend() ->
> genphy_suspend()
> // set BMCR_PDOWN bit in MII_BMCR
>
> In genphy_suspend() setting the BMCR_PDWN bit in MII_BMCR switches the PHY
> to Software Power-Down (SPD) mode (according to the KSZ9131 datasheet).
> Thus, when opening the interface after it has been previously closed (via
> ravb_close()), the phydev->drv->config_init() and
> phydev->drv->config_intr() reach the KSZ9131 PHY driver via the
> ksz9131_config_init() and kszphy_config_intr() functions.
>
> KSZ9131 specifies that the MII management interface remains operational
> during SPD (Software Power-Down), but (according to manual):
> - Only access to the standard registers (0 through 31) is supported.
> - Access to MMD address spaces other than MMD address space 1 is possible
> if the spd_clock_gate_override bit is set.
> - Access to MMD address space 1 is not possible.
>
> The spd_clock_gate_override bit is not used in the KSZ9131 driver.
>
> ksz9131_config_init() configures RGMII delay, pad skews and LEDs by
> accessesing MMD registers other than those in address space 1.
>
> The datasheet for the KSZ9131 does not specify what happens if registers
> from an unsupported address space are accessed while the PHY is in SPD.
>
> To fix the issue the .soft_reset method has been instantiated for KSZ9131,
> too. This resets the PHY to the default state before doing any
> configurations to it, thus switching it out of SPD.
>
> Fixes: bff5b4b37372 ("net: phy: micrel: add Microchip KSZ9131 initial driver")
> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
> ---
> drivers/net/phy/micrel.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> index 08e3915001c3..f31f03dd87dd 100644
> --- a/drivers/net/phy/micrel.c
> +++ b/drivers/net/phy/micrel.c
> @@ -4842,6 +4842,7 @@ static struct phy_driver ksphy_driver[] = {
> .flags = PHY_POLL_CABLE_TEST,
> .driver_data = &ksz9131_type,
> .probe = kszphy_probe,
> + .soft_reset = genphy_soft_reset,
> .config_init = ksz9131_config_init,
> .config_intr = kszphy_config_intr,
> .config_aneg = ksz9131_config_aneg,
This looks good to me. Thanks for the detailed analysis,
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
next prev parent reply other threads:[~2024-01-05 9:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-05 8:52 [PATCH net] net: phy: micrel: populate .soft_reset for KSZ9131 Claudiu
2024-01-05 9:43 ` Russell King (Oracle)
2024-01-05 14:36 ` Andrew Lunn
2024-01-05 15:53 ` Maxime Chevallier
2024-01-10 13:20 ` claudiu beznea
2024-01-12 1:30 ` Andrew Lunn
2024-01-05 9:43 ` Maxime Chevallier [this message]
2024-01-12 11:10 ` patchwork-bot+netdevbpf
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=20240105104323.76ddfdca@device-28.home \
--to=maxime.chevallier@bootlin.com \
--cc=andrew@lunn.ch \
--cc=claudiu.beznea.uj@bp.renesas.com \
--cc=claudiu.beznea@tuxon.dev \
--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=yuiko.oshino@microchip.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