In cs35l56_process_xu_onchip_speaker_id() the warning that the number
of pulls != number of GPIOs should only be printed if pulls are defined.

Pull settings are optional because there would normally be an external
resistor providing the pull. The warning would still be true if pulls
are not defined, but in that case is just log noise.

While we're changing that block of code, also fix the indenting of the
arguments to the dev_warn().

Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
---
 sound/soc/codecs/cs35l56.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/cs35l56.c b/sound/soc/codecs/cs35l56.c
index 3bf9e8fc34a2..37909a319f88 100644
--- a/sound/soc/codecs/cs35l56.c
+++ b/sound/soc/codecs/cs35l56.c
@@ -1625,9 +1625,9 @@ static int cs35l56_process_xu_onchip_speaker_id(struct cs35l56_private *cs35l56,
 	if (num_pulls < 0)
 		return num_pulls;
 
-	if (num_pulls != num_gpios) {
+	if (num_pulls && (num_pulls != num_gpios)) {
 		dev_warn(cs35l56->base.dev, "%s count(%d) != %s count(%d)\n",
-			pull_name, num_pulls, gpio_name, num_gpios);
+			 pull_name, num_pulls, gpio_name, num_gpios);
 	}
 
 	ret = cs35l56_check_and_save_onchip_spkid_gpios(&cs35l56->base,
-- 
2.47.3

On Thu, 26 Feb 2026 11:35:11 +0000, Richard Fitzgerald wrote:
> In cs35l56_process_xu_onchip_speaker_id() the warning that the number
> of pulls != number of GPIOs should only be printed if pulls are defined.
> 
> Pull settings are optional because there would normally be an external
> resistor providing the pull. The warning would still be true if pulls
> are not defined, but in that case is just log noise.
> 
> [...]

Applied to

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Thanks!

[1/1] ASoC: cs35l56: Suppress pointless warning about number of GPIO pulls
      commit: ca5056f5a78ce62588878d138e8141f01d70e61b

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark