[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <70a44ceb-2d52-4189-af42-b56e8f60d0f2@amd.com>
Date: Tue, 6 Feb 2024 21:14:21 +0530
From: "Karumanchi, Vineeth" <vineeth.karumanchi@....com>
To: claudiu beznea <claudiu.beznea@...on.dev>, nicolas.ferre@...rochip.com,
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
Cc: netdev@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org, git@....com
Subject: Re: [PATCH net-next 1/3] net: macb: queue tie-off or disable during
WOL suspend
Hi Claudiu,
On 2/3/2024 9:08 PM, claudiu beznea wrote:
<...>
>> + for (q = 0, queue = bp->queues; q < bp->num_queues;
>> + ++q, ++queue) {
>> + /* Disable RX queues */
> Operation in this for loop could be moved in the the above IRQ disable
> loop. Have you tried it? are there any issues with it?
OK. I haven't tried it. I will try and update.
>
>> + if (bp->caps & MACB_CAPS_QUEUE_DISABLE) {
>> + queue_writel(queue, RBQP, GEM_RBQP_DISABLE);
>> + } else {
>> + /* Tie off RX queues */
>> + queue_writel(queue, RBQP,
>> + lower_32_bits(bp->rx_ring_tieoff_dma));
> I think this should be guarded by:
> #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT
>> + queue_writel(queue, RBQPH,
>> + upper_32_bits(bp->rx_ring_tieoff_dma));
>> + }
>> + }
>> + /* Enable Receive engine */
>> + ctrlmask = macb_readl(bp, NCR);
> Is this needed?
Yes, not needed, we can use earlier value directly.
>
>> + ctrlmask |= MACB_BIT(RE);
<...>
--
🙏 vineeth
Powered by blists - more mailing lists