public inbox for linux-i3c@lists.infradead.org
 help / color / mirror / Atom feed
* [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax
@ 2025-12-08  2:07 Krzysztof Kozlowski
  2025-12-08  2:07 ` [PATCH 2/2] i3c: adi: " Krzysztof Kozlowski
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Krzysztof Kozlowski @ 2025-12-08  2:07 UTC (permalink / raw)
  To: Alexandre Belloni, Frank Li, Jorge Marques, linux-i3c,
	linux-kernel
  Cc: Krzysztof Kozlowski

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 <krzysztof.kozlowski@oss.qualcomm.com>
---
 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;
 
-- 
2.51.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* [PATCH 2/2] i3c: adi: Fix confusing cleanup.h syntax
  2025-12-08  2:07 [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax Krzysztof Kozlowski
@ 2025-12-08  2:07 ` Krzysztof Kozlowski
  2025-12-08 15:50 ` [PATCH 1/2] i3c: master: " Frank Li
  2025-12-12 23:07 ` Alexandre Belloni
  2 siblings, 0 replies; 5+ messages in thread
From: Krzysztof Kozlowski @ 2025-12-08  2:07 UTC (permalink / raw)
  To: Alexandre Belloni, Frank Li, Jorge Marques, linux-i3c,
	linux-kernel
  Cc: Krzysztof Kozlowski

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.

Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
 drivers/i3c/master/adi-i3c-master.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/i3c/master/adi-i3c-master.c b/drivers/i3c/master/adi-i3c-master.c
index 82ac0b3d057a..8df62370b6bb 100644
--- a/drivers/i3c/master/adi-i3c-master.c
+++ b/drivers/i3c/master/adi-i3c-master.c
@@ -332,10 +332,9 @@ static int adi_i3c_master_send_ccc_cmd(struct i3c_master_controller *m,
 				       struct i3c_ccc_cmd *cmd)
 {
 	struct adi_i3c_master *master = to_adi_i3c_master(m);
-	struct adi_i3c_xfer *xfer __free(kfree) = NULL;
 	struct adi_i3c_cmd *ccmd;
 
-	xfer = adi_i3c_master_alloc_xfer(master, 1);
+	struct adi_i3c_xfer *xfer __free(kfree) = adi_i3c_master_alloc_xfer(master, 1);
 	if (!xfer)
 		return -ENOMEM;
 
@@ -371,13 +370,12 @@ static int adi_i3c_master_priv_xfers(struct i3c_dev_desc *dev,
 {
 	struct i3c_master_controller *m = i3c_dev_get_master(dev);
 	struct adi_i3c_master *master = to_adi_i3c_master(m);
-	struct adi_i3c_xfer *xfer __free(kfree) = NULL;
 	int i, ret;
 
 	if (!nxfers)
 		return 0;
 
-	xfer = adi_i3c_master_alloc_xfer(master, nxfers);
+	struct adi_i3c_xfer *xfer __free(kfree) = adi_i3c_master_alloc_xfer(master, nxfers);
 	if (!xfer)
 		return -ENOMEM;
 
@@ -777,7 +775,6 @@ static int adi_i3c_master_i2c_xfers(struct i2c_dev_desc *dev,
 {
 	struct i3c_master_controller *m = i2c_dev_get_master(dev);
 	struct adi_i3c_master *master = to_adi_i3c_master(m);
-	struct adi_i3c_xfer *xfer __free(kfree) = NULL;
 	int i;
 
 	if (!nxfers)
@@ -786,7 +783,8 @@ static int adi_i3c_master_i2c_xfers(struct i2c_dev_desc *dev,
 		if (xfers[i].flags & I2C_M_TEN)
 			return -EOPNOTSUPP;
 	}
-	xfer = adi_i3c_master_alloc_xfer(master, nxfers);
+
+	struct adi_i3c_xfer *xfer __free(kfree) = adi_i3c_master_alloc_xfer(master, nxfers);
 	if (!xfer)
 		return -ENOMEM;
 
-- 
2.51.0


-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax
  2025-12-08  2:07 [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax Krzysztof Kozlowski
  2025-12-08  2:07 ` [PATCH 2/2] i3c: adi: " Krzysztof Kozlowski
@ 2025-12-08 15:50 ` Frank Li
  2025-12-08 21:14   ` Alexandre Belloni
  2025-12-12 23:07 ` Alexandre Belloni
  2 siblings, 1 reply; 5+ messages in thread
From: Frank Li @ 2025-12-08 15:50 UTC (permalink / raw)
  To: Krzysztof Kozlowski
  Cc: Alexandre Belloni, Jorge Marques, linux-i3c, linux-kernel

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 <krzysztof.kozlowski@oss.qualcomm.com>
> ---
>  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.

Frank




>
> --
> 2.51.0
>

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax
  2025-12-08 15:50 ` [PATCH 1/2] i3c: master: " Frank Li
@ 2025-12-08 21:14   ` Alexandre Belloni
  0 siblings, 0 replies; 5+ messages in thread
From: Alexandre Belloni @ 2025-12-08 21:14 UTC (permalink / raw)
  To: Frank Li; +Cc: Krzysztof Kozlowski, Jorge Marques, linux-i3c, linux-kernel

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 <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> >  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

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax
  2025-12-08  2:07 [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax Krzysztof Kozlowski
  2025-12-08  2:07 ` [PATCH 2/2] i3c: adi: " Krzysztof Kozlowski
  2025-12-08 15:50 ` [PATCH 1/2] i3c: master: " Frank Li
@ 2025-12-12 23:07 ` Alexandre Belloni
  2 siblings, 0 replies; 5+ messages in thread
From: Alexandre Belloni @ 2025-12-12 23:07 UTC (permalink / raw)
  To: Frank Li, Jorge Marques, linux-i3c, linux-kernel,
	Krzysztof Kozlowski

On Mon, 08 Dec 2025 03:07:51 +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."
> 
> [...]

Applied, thanks!

[1/2] i3c: master: Fix confusing cleanup.h syntax
      https://git.kernel.org/abelloni/c/cc3b18f9fede
[2/2] i3c: adi: Fix confusing cleanup.h syntax
      https://git.kernel.org/abelloni/c/136209e6bd98

Best regards,

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-- 
linux-i3c mailing list
linux-i3c@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-i3c

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2025-12-12 23:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-12-08  2:07 [PATCH 1/2] i3c: master: Fix confusing cleanup.h syntax Krzysztof Kozlowski
2025-12-08  2:07 ` [PATCH 2/2] i3c: adi: " Krzysztof Kozlowski
2025-12-08 15:50 ` [PATCH 1/2] i3c: master: " Frank Li
2025-12-08 21:14   ` Alexandre Belloni
2025-12-12 23:07 ` Alexandre Belloni

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox