From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-03.galae.net (smtpout-03.galae.net [185.246.85.4]) (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 05929F9C0 for ; Mon, 8 Dec 2025 21:14:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.246.85.4 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765228475; cv=none; b=nEXB/oBfQrZPkqL+rGFhCOysgROhBbiDHbvpzRYJtynhsuA+Kjvi7I/E5jwbFJR3hTLE1PbBsKWxPAMkIBbnJGqPEykaThebiDCSGMu3Lvd2cJmCPKe4A9wLA0YKHIumkkcYbndfCvAXvHaRDCXJp24T//fANuO/SnrjvqOgu/I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765228475; c=relaxed/simple; bh=2HjpapYF5uegP7kW+7Vbz6GGuyLyT0zsEhMUYuV8k1c=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=j1VR0AwYFEa+Ccx+OcDe6KnJfiWyLnE72a3HL8hQn33CWHvV//KlJw5ZJYsLtwyALo92jL/xc9d4JTjG1Rv7Bu0VgNDCZFtD+KCH5QSLhqibIg1wV06siKKQ9lzomll4tItNU/Iz9927JFXXCqdtrlA9cshHUjRjGI+9/dl9Ads= 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=IUIdMY/3; arc=none smtp.client-ip=185.246.85.4 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="IUIdMY/3" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-03.galae.net (Postfix) with ESMTPS id DE21B4E41AF9 for ; Mon, 8 Dec 2025 21:14:27 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id 8FD33606DD; Mon, 8 Dec 2025 21:14:27 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id 31827103C8D5C; Mon, 8 Dec 2025 22:14:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1765228467; h=from:subject:date:message-id:to:cc:mime-version:content-type: in-reply-to:references; bh=UMFT6VG7jWFLIe582DxUJnepXZaYsQcmdz9buJiE4Vs=; b=IUIdMY/3vkIQDsrkI/x0ClMZe0zc/bKSo5mxJGwUq8mkJ6yK8Z1yAiijJfRcP30Difs2Re EQTigSJS7SVg33H+TwvOsuZq1dEvYrHg5T2ataP+kUrGTWp2h6wv5Pbb30XrjO4KkGWNUf OtKGPuyuyDUik3jFS1rxXZwb3ymdYvF5D1OkaYf8b2dzuPLOZlXgpQxzTIHUXNsotIzLWY Vk1OKII2GQo8P1Ylsix3hBiJP1X3roc4Sxn9soHixNqA7V6vIIxqRyluAITyaGBGnFJxQ7 ya3r40riWC1oE/RF0d8DuI2939Y0PyLG6xwJ08k4gkq4m1xWDUlweT3tLw51wQ== Date: Mon, 8 Dec 2025 22:14:24 +0100 From: Alexandre Belloni To: Frank Li Cc: Krzysztof Kozlowski , Jorge Marques , linux-i3c@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax Message-ID: <20251208211424c71a5829@mail.local> References: <20251208020750.4727-3-krzysztof.kozlowski@oss.qualcomm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Last-TLS-Session-Version: TLSv1.3 Hello Frank, On 08/12/2025 10:50:50-0500, Frank Li wrote: > On Mon, Dec 08, 2025 at 03:07:51AM +0100, Krzysztof Kozlowski wrote: > > Initializing automatic __free variables to NULL without need (e.g. > > branches with different allocations), followed by actual allocation is > > in contrary to explicit coding rules guiding cleanup.h: > > > > "Given that the "__free(...) = NULL" pattern for variables defined at > > the top of the function poses this potential interdependency problem the > > recommendation is to always define and assign variables in one statement > > and not group variable definitions at the top of the function when > > __free() is used." > > > > Code does not have a bug, but is less readable and uses discouraged > > coding practice, so fix that by moving declaration to the place of > > assignment. > > > > Not that other existing usage of __free() in this context is a corret > > exception initialized to NULL, because the actual allocation is branched > > in if(). > > > > Signed-off-by: Krzysztof Kozlowski > > --- > > drivers/i3c/master.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c > > index 823661a81f5e..62437a899cdc 100644 > > --- a/drivers/i3c/master.c > > +++ b/drivers/i3c/master.c > > @@ -1742,11 +1742,10 @@ EXPORT_SYMBOL_GPL(i3c_master_do_daa); > > struct i3c_dma *i3c_master_dma_map_single(struct device *dev, void *buf, > > size_t len, bool force_bounce, enum dma_data_direction dir) > > { > > - struct i3c_dma *dma_xfer __free(kfree) = NULL; > > void *bounce __free(kfree) = NULL; > > void *dma_buf = buf; > > > > - dma_xfer = kzalloc(sizeof(*dma_xfer), GFP_KERNEL); > > + struct i3c_dma *dma_xfer __free(kfree) = kzalloc(sizeof(*dma_xfer), GFP_KERNEL); > > if (!dma_xfer) > > return NULL; > > According to thread > https://lore.kernel.org/all/CAHk-=whPZoi03ZwphxiW6cuWPtC3nyKYS8_BThgztCdgPWP1WA@mail.gmail.com/ > "But again: I don't want to make this some kind of hard rule, and I > think it should be done judiciously and with taste, not some kind of > crazy conversion thing." > > And there are not logic code between declear and kzalloc. > https://lore.kernel.org/all/CAHk-=wjMMSAaqTjBSfYenfuzE1bMjLj+2DLtLWJuGt07UGCH_Q@mail.gmail.com/ > struct ring_buffer_per_cpu *cpu_buffer __free(kfree); > > cpu_buffer = kzalloc_node(...); > > as separate things (but probably next to each other, so that the > "__free(kfree)" part makes sense because the allocation is right > there)." > > void *bounce __free(kfree) = NULL, still be there. Only cleanup one is > not enough valuable. > > https://lore.kernel.org/all/CAHk-=wjMMSAaqTjBSfYenfuzE1bMjLj+2DLtLWJuGt07UGCH_Q@mail.gmail.com/#t > " would then make that otherwise nasty allocation then become just > > auto cpu_buffer __free(kfree) = cpu_buffer_alloc(); > " > > Maybe we can defer this cleanup after kernel using "auto" keywords widely. While you are absolutely correct, I'll apply those just because else we'll get many people submitting the same patch and it indeed makes the code nicer. -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com