[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <LV8PR11MB8700D54F5E03440681BF0D449F172@LV8PR11MB8700.namprd11.prod.outlook.com>
Date: Thu, 25 Apr 2024 11:37:12 +0000
From: <Raju.Lakkaraju@...rochip.com>
To: <andrew@...n.ch>
CC: <netdev@...r.kernel.org>, <davem@...emloft.net>, <kuba@...nel.org>,
<pabeni@...hat.com>, <edumazet@...gle.com>, <linux-kernel@...r.kernel.org>,
<Bryan.Whitehead@...rochip.com>, <UNGLinuxDriver@...rochip.com>
Subject: RE: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY
does not
Hi Andrew,
Thank you for quick response and valuable suggestions.
> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: Wednesday, April 24, 2024 12:41 AM
> To: Raju Lakkaraju - I30499 <Raju.Lakkaraju@...rochip.com>
> Cc: netdev@...r.kernel.org; davem@...emloft.net; kuba@...nel.org;
> pabeni@...hat.com; edumazet@...gle.com; linux-kernel@...r.kernel.org;
> Bryan Whitehead - C21958 <Bryan.Whitehead@...rochip.com>;
> UNGLinuxDriver <UNGLinuxDriver@...rochip.com>
> Subject: Re: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when
> PHY does not
>
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the
> content is safe
>
> > If we don't enable/register the PCI11x1x's ethernet device in wake
> > list by calling " device_set_wakeup_enable( )" function, device power
> > state shows as disable.
>
> > PHY (GPY211C)'s interrupt pin (MDINT) connect to PCI11x1x's ethernet
> device.
>
> > When I configure the WAKE_PHY or WAKE_MAGIC on GPY211C PHY,
> Interrupt
> > generation observed when magic packet or link activity (link down or
> > link up). If wakeup enable in PCI11x1x's ethernet device, System
> > resumes from sleep.
>
> This is the bit that is missing from your commit message, and maybe it should
> be in a comment. The interrupt controller is part of the MAC. So you need to
> leave MAC burning power, maybe even processing packets, because you
> cannot disable the MAC but leave the interrupt controller functioning, so that
> it can trigger a wake up via PCIe.
>
> There are a few things you should consider:
>
> Call phy_speed_down(). This will renegotiate the link, dropping it to the
> slowest speed both link partners support. So hopefully down to 10Mbps.
> Your MAC will then only need to pointlessly process 10Mbps of packets,
> rather than 1Gbps.
>
If PHY handles the magic packet or phy activity (i.e. WAKE_MAGIC or WAKE_PHY), our PCI11x1x's MAC will handle only interrupt (MDINT from PHY). Not MAC's magic packet.
In this case do we really call phy_speed_down( ) ?
In case of WAKE_PHY enable and put system in suspend mode, I'm seeing issues with calling phy_speed_down().
When speed change occurs, Link interrupt occurs by Link partner which internally system resume from sleep.
Do we need to call phy_speed_down( ) for only magic packet (WAKE_MAGIC) case only ?
> See if you can disable parts of the MAC, in particularly the receive engine, in
> order to save power.
>
> Talk to your hardware engineer and see if the next generation of the
> hardware can separate the interrupt controller from the MAC, so you can
> disable the MAC and leave the interrupt controller functioning.
>
> > Please find the attached prototype code change (Temporary patch)for
> reference.
> > I will submit this patch separately.
>
Sure. I will do.
> Please just submit it in the normal way for review.
>
> Andrew
Thanks,
Raju
Powered by blists - more mailing lists