From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 63AB0310655; Thu, 2 Apr 2026 13:57:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775138273; cv=none; b=Zw+QkJTbFJ+MOj7jse4hIm0lCZYd47MGMh0Spc4hupu1v4mj3NUd/EDzohFjxiRDK3WBXREm7tqliua34n9Y51/eDUZiqbuwDTHz123GFmQwnNxyVdFunGnU7Gk1zeDHOc1mywSFIKgAE+AU4ZTmQT7K1gZqjpAKHNgxShHIbkE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1775138273; c=relaxed/simple; bh=B6XHVrDu4cRpr7JHMEQjOwY23wmaawcouOP1Kt6Y9e8=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:To:From:Subject: References:In-Reply-To; b=WhjBTZ+JX4K+UVkm7CQF+JZOk7/TFjlI7JkNh/JW3qdBo/yv3/AWsZtrpI09/5oeDls7G8+BDGVijTGr+Z59lS3NHhBjiubnIagwZe31Z2aPaBucxQpJ3pCz7LLpSfH3W6GfZtzcSs59xFUnz7QdGedhatSsrV+wHSBZ7Zi7BOE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=gaM0wYYg; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="gaM0wYYg" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 96244C59F46; Thu, 2 Apr 2026 13:58:18 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 174255FDEB; Thu, 2 Apr 2026 13:57:47 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B5F4110450264; Thu, 2 Apr 2026 15:57:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1775138266; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=GkRbx1KLnlIONYrPbKgeBqIosRCm1oaDFZI+qcdxXlQ=; b=gaM0wYYgUCY8eKzjNEC0Z1n6a5u1rokGSWlWgR1p3OFbr8YNzqg6e3uJE9sKjJmOosPhX9 cPro91YokI7JDnbu64PGC4BEIZ1eiJsmKljOlzOdBRPghPpbl3ZcGnUBcWqRXrHRXim1xO y5arF9M635+cdEMKgY6Tk7PDs6O91MqE7SvaEVE3hnRQi3e+goWZnWCXrXYiJEneqpMpij VkguGkRnBepqCpckpdkuy0bt2tPTznvK0cXGeB1tU2aaCy2KzmuKdzqqk36R7hExZKO/16 PPAowRDQ+hB9KQ+M5/kc8lCRN8Nhzo6VR0PKSWy30rcXqsquz0+ok4O18qB+MQ== Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Thu, 02 Apr 2026 15:57:41 +0200 Message-Id: Cc: "Nicolas Ferre" , "Claudiu Beznea" , "Andrew Lunn" , "David S. Miller" , "Eric Dumazet" , "Jakub Kicinski" , "Paolo Abeni" , "Richard Cochran" , "Russell King" , "Paolo Valerio" , "Conor Dooley" , "Vladimir Kondratiev" , "Gregory CLEMENT" , =?utf-8?q?Beno=C3=AEt_Monin?= , "Tawfik Bayouk" , "Thomas Petazzoni" , "Maxime Chevallier" , , To: "Nicolai Buchwitz" , =?utf-8?q?Th=C3=A9o_Lebrun?= From: =?utf-8?q?Th=C3=A9o_Lebrun?= Subject: Re: [PATCH net-next 05/11] net: macb: allocate tieoff descriptor once across device lifetime X-Mailer: aerc 0.21.0-0-g5549850facc2 References: <20260401-macb-context-v1-0-9590c5ab7272@bootlin.com> <20260401-macb-context-v1-5-9590c5ab7272@bootlin.com> <8c500ccc919ac2d7b350eacca0ab6ccf@tipi-net.de> In-Reply-To: <8c500ccc919ac2d7b350eacca0ab6ccf@tipi-net.de> X-Last-TLS-Session-Version: TLSv1.3 On Thu Apr 2, 2026 at 1:14 PM CEST, Nicolai Buchwitz wrote: > On 1.4.2026 18:39, Th=C3=A9o Lebrun wrote: >> The tieoff descriptor is a RX DMA descriptor ring of size one. It gets >> configured onto queues for Wake-on-LAN during system-wide suspend when >> hardware does not support disabling individual queues >> (MACB_CAPS_QUEUE_DISABLE). >>=20 >> MACB/GEM driver allocates it alongside the main RX ring >> inside macb_alloc_consistent() at open. Free is done by >> macb_free_consistent() at close. >>=20 >> Change to allocate once at probe and free on probe failure or device >> removal. This makes the tieoff descriptor lifetime much longer, >> avoiding repeating coherent buffer allocation on each open/close cycle. >>=20 >> Main benefit: we dissociate its lifetime from the main ring's lifetime. >> That way there is less work to be doing on resources (re)alloc. This >> currently happens on close/open, but will soon also happen on context >> swap operations (set_ringparam, change_mtu, set_channels, etc). >>=20 >> Signed-off-by: Th=C3=A9o Lebrun >> --- >> drivers/net/ethernet/cadence/macb_main.c | 70=20 >> ++++++++++++++++---------------- > >> [...] > >>=20 >> +static int macb_alloc_tieoff(struct macb *bp) >> +{ >> + /* Tieoff is a workaround in case HW cannot disable queues, for PM.=20 >> */ >> + if (bp->caps & MACB_CAPS_QUEUE_DISABLE) >> + return 0; >> + >> + bp->rx_ring_tieoff =3D dma_alloc_coherent(&bp->pdev->dev, >> + macb_dma_desc_get_size(bp), >> + &bp->rx_ring_tieoff_dma, >> + GFP_KERNEL); >> + if (!bp->rx_ring_tieoff) >> + return -ENOMEM; >> + >> + return 0; >> +} > > The old macb_init_tieoff() that wrote WRAP+USED into the > descriptor is deleted but its work is not replicated here. > dma_alloc_coherent zeroes the memory, so RX_USED=3D0 and the > hardware will treat it as a valid receive buffer pointing to > DMA address 0 during suspend. > > Shouldn't this have a macb_set_addr() + ctrl=3D0 after the > allocation? Clearly! This V1 uses tieoff uninitialised. The two instructions from old macb_init_tieoff() have been appended to macb_alloc_tieoff(). static int macb_alloc_tieoff(struct macb *bp) { /* Tieoff is a workaround in case HW cannot disable queues, for PM. */ if (bp->caps & MACB_CAPS_QUEUE_DISABLE) return 0; bp->rx_ring_tieoff =3D dma_alloc_coherent(&bp->pdev->dev, macb_dma_desc_get_size(bp), &bp->rx_ring_tieoff_dma, GFP_KERNEL); if (!bp->rx_ring_tieoff) return -ENOMEM; macb_set_addr(bp, bp->rx_ring_tieoff, MACB_BIT(RX_WRAP) | MACB_BIT(RX_USED)); bp->rx_ring_tieoff->ctrl =3D 0; return 0; } Thanks, -- Th=C3=A9o Lebrun, Bootlin Embedded Linux and Kernel engineering https://bootlin.com