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: Tue, 23 Apr 2024 21:10:51 +0200
From: Andrew Lunn <andrew@...n.ch>
To: 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@...rochip.com,
	UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net V2 2/2] net: lan743x: support WOL in MAC even when
 PHY does not

> 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.

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.

Please just submit it in the normal way for review.

       Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ