linux-kernel - RE: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when PHY does not

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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