netdev - Re: [PATCH net-next v7 1/4] net: macb: queue tie-off or disable during WOL suspend

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: Sat, 22 Jun 2024 21:14:32 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Vineeth Karumanchi <vineeth.karumanchi@....com>
Cc: nicolas.ferre@...rochip.com, claudiu.beznea@...on.dev,
	davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
	pabeni@...hat.com, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	linux@...linux.org.uk, vadim.fedorenko@...ux.dev,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org, git@....com
Subject: Re: [PATCH net-next v7 1/4] net: macb: queue tie-off or disable
 during WOL suspend

On Fri, Jun 21, 2024 at 10:27:32AM +0530, Vineeth Karumanchi wrote:
> When GEM is used as a wake device, it is not mandatory for the RX DMA
> to be active. The RX engine in IP only needs to receive and identify
> a wake packet through an interrupt. The wake packet is of no further
> significance; hence, it is not required to be copied into memory.
> By disabling RX DMA during suspend, we can avoid unnecessary DMA
> processing of any incoming traffic.
> 
> During suspend, perform either of the below operations:
> 
> - tie-off/dummy descriptor: Disable unused queues by connecting
>   them to a looped descriptor chain without free slots.
> 
> - queue disable: The newer IP version allows disabling individual queues.
> 
> Co-developed-by: Harini Katakam <harini.katakam@....com>
> Signed-off-by: Harini Katakam <harini.katakam@....com>
> Signed-off-by: Vineeth Karumanchi <vineeth.karumanchi@....com>

Reviewed-by: Andrew Lunn <andrew@...n.ch>

    Andrew