All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
	Takashi Iwai <tiwai@suse.com>,
	Maciej Strozek <mstrozek@opensource.cirrus.com>,
	Bard Liao <yung-chuan.liao@linux.intel.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
	linux-sound@vger.kernel.org, linux-kernel@vger.kernel.org,
	patches@opensource.cirrus.com
Subject: Re: [PATCH 3/3] ASoC: SDCA: functions: Fix confusing cleanup.h syntax
Date: Thu, 4 Dec 2025 11:26:19 +0000	[thread overview]
Message-ID: <aTFv2zyDC13VXg2R@opensource.cirrus.com> (raw)
In-Reply-To: <20251203-asoc-wrong-cleanup-h-continued-v1-3-5142be4874fb@oss.qualcomm.com>

On Wed, Dec 03, 2025 at 05:12:40PM +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.
> 
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---

Hmm... yeah a fair point. Can't say I love the inline
declarations but I guess I will get used to it.

I wonder if for consistency we should do something about
the __free in find_sdca_init_table as well. One could move
the alloc to before the error checks, does risk doing an
unecessary alloc but its on the error path so I don't feel like
performance matters. Or rather than sizeof(*raw) we could just
do sizeof(struct raw_init_write)?

But if you would rather leave as is I don't mind either so:

Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

  reply	other threads:[~2025-12-04 11:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-03 16:12 [PATCH 0/3] ASoC: amd/sdw: Fix confusing cleanup.h Krzysztof Kozlowski
2025-12-03 16:12 ` [PATCH 1/3] ASoC: amd: acp-sdw-legacy: Fix confusing cleanup.h syntax Krzysztof Kozlowski
2025-12-03 16:12 ` [PATCH 2/3] ASoC: amd: acp-sdw-sof: " Krzysztof Kozlowski
2025-12-03 16:12 ` [PATCH 3/3] ASoC: SDCA: functions: " Krzysztof Kozlowski
2025-12-04 11:26   ` Charles Keepax [this message]
2025-12-04 11:59     ` Krzysztof Kozlowski
2025-12-04 16:18       ` Charles Keepax
2025-12-15 13:58 ` [PATCH 0/3] ASoC: amd/sdw: Fix confusing cleanup.h Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aTFv2zyDC13VXg2R@opensource.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=broonie@kernel.org \
    --cc=krzysztof.kozlowski@oss.qualcomm.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sound@vger.kernel.org \
    --cc=mstrozek@opensource.cirrus.com \
    --cc=patches@opensource.cirrus.com \
    --cc=perex@perex.cz \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=tiwai@suse.com \
    --cc=yung-chuan.liao@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.