mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Biju Das <biju.das.jz@bp.renesas.com>
To: Paolo Abeni <pabeni@redhat.com>, Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Russell King <linux@armlinux.org.uk>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>,
	biju.das.au <biju.das.au@gmail.com>,
	"linux-renesas-soc@vger.kernel.org"
	<linux-renesas-soc@vger.kernel.org>
Subject: RE: [PATCH net-next] net: phy: micrel: Add callback for restoring context
Date: Thu, 10 Jul 2025 17:43:50 +0000	[thread overview]
Message-ID: <TY3PR01MB11346D7C845C06A40407A83528648A@TY3PR01MB11346.jpnprd01.prod.outlook.com> (raw)
In-Reply-To: <60e77fb5-ef9f-4c89-899d-398cd9eb8f85@redhat.com>

Hi Paolo Abeni,

Thanks for the feedback.

> -----Original Message-----
> From: Paolo Abeni <pabeni@redhat.com>
> Sent: 10 July 2025 14:38
> Subject: Re: [PATCH net-next] net: phy: micrel: Add callback for restoring context
> 
> On 7/7/25 4:29 PM, Biju Das wrote:
> > @@ -374,6 +376,7 @@ static struct kszphy_hw_stat kszphy_hw_stats[] = {
> > };
> >
> >  struct kszphy_type {
> > +	void (*resume)(struct phy_device *phydev);
> >  	u32 led_mode_reg;
> >  	u16 interrupt_level_mask;
> >  	u16 cable_diag_reg;
> 
> Why adding another callback? I think you could avoid it using a ksz9131-specific phy_driver->resume.

It is being called from open() as well see [1]

[1]
[    1.934177]  kszphy_resume+0x18/0xc4
[    1.934193]  phy_resume+0x3c/0x74
[    1.934207]  phy_attach_direct+0x1bc/0x398
[    1.934220]  phylink_fwnode_phy_connect+0xb0/0x130
[    1.934237]  __stmmac_open+0xe4/0x50c
[    1.934251]  stmmac_open+0x44/0xd4

> 
> > @@ -444,6 +447,7 @@ struct kszphy_priv {
> >  	bool rmii_ref_clk_sel;
> >  	bool rmii_ref_clk_sel_val;
> >  	bool clk_enable;
> > +	bool is_suspended;
> >  	u64 stats[ARRAY_SIZE(kszphy_hw_stats)];
> >  	struct kszphy_phy_stats phy_stats;
> >  };
> > @@ -491,6 +495,7 @@ static const struct kszphy_type ksz9021_type = {
> > };
> >
> >  static const struct kszphy_type ksz9131_type = {
> > +	.resume = ksz9131_restore_rgmii_delay,
> >  	.interrupt_level_mask	= BIT(14),
> >  	.disable_dll_tx_bit	= BIT(12),
> >  	.disable_dll_rx_bit	= BIT(12),
> > @@ -1387,6 +1392,12 @@ static int ksz9131_config_rgmii_delay(struct phy_device *phydev)
> >  			      txcdll_val);
> >  }
> >
> > +static void ksz9131_restore_rgmii_delay(struct phy_device *phydev) {
> > +	if (phy_interface_is_rgmii(phydev))
> > +		ksz9131_config_rgmii_delay(phydev);
> > +}
> > +
> >  /* Silicon Errata DS80000693B
> >   *
> >   * When LEDs are configured in Individual Mode, LED1 is ON in a
> > no-link @@ -2345,6 +2356,11 @@ static int
> > kszphy_generic_suspend(struct phy_device *phydev)
> >
> >  static int kszphy_suspend(struct phy_device *phydev)  {
> > +	struct kszphy_priv *priv = phydev->priv;
> > +
> > +	if (priv)
> > +		priv->is_suspended = true;
> 
> Under which circumstances `priv` could be NULL? AFAICS it should always not NULL after probe.

On the kszphy_config_init(), there is a check for NULL. That is the reason for adding it here.

Yor right, priv cannot be NULL after probe.


> 
> > +
> >  	/* Disable PHY Interrupts */
> >  	if (phy_interrupt_is_valid(phydev)) {
> >  		phydev->interrupts = PHY_INTERRUPT_DISABLED; @@ -2381,8 +2397,17 @@
> > static void kszphy_parse_led_mode(struct phy_device *phydev)
> >
> >  static int kszphy_resume(struct phy_device *phydev)  {
> > +	struct kszphy_priv *priv = phydev->priv;
> >  	int ret;
> >
> > +	if (priv && priv->is_suspended) {
> 
> I think you can use phydev->suspended instead of adding another flag.

Yes, I can use phydev->suspended as phylink_prepare_resume() calls phy_resume()
with phydev->suspended set.
> 
> Also, can resume be invoked without the phydev being suspended?

Yes, phy_attach_direct() during open() invokes resume.

Cheers,
Biju

      reply	other threads:[~2025-07-10 17:44 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-07 14:29 Biju Das
2025-07-10 13:38 ` Paolo Abeni
2025-07-10 17:43   ` Biju Das [this message]

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=TY3PR01MB11346D7C845C06A40407A83528648A@TY3PR01MB11346.jpnprd01.prod.outlook.com \
    --to=biju.das.jz@bp.renesas.com \
    --cc=andrew@lunn.ch \
    --cc=biju.das.au@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=geert+renesas@glider.be \
    --cc=hkallweit1@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=prabhakar.mahadev-lad.rj@bp.renesas.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

all inboxes | Powered by JetHome®