linux-kernel - Re: [RFC 3/3] ASoC: simple-card: Split alloc and init logics in probe function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <10a207cc-7a9b-4cb7-a76d-04dd0c5a55e1@redaril.me>
Date: Sat, 24 Jan 2026 11:23:40 +0100
From: Fabio <fabio@...aril.me>
To: Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>
Cc: Fabio Forni <development@...aril.me>, Mark Brown <broonie@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>, Jaroslav Kysela <perex@...ex.cz>,
 Takashi Iwai <tiwai@...e.com>, linux-sound@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [RFC 3/3] ASoC: simple-card: Split alloc and init logics in probe
 function

Hi, here I am.

> But I have thought that the style like below can easy for people ?
> (A) part checks something and return error, then indicate error reasons.
> (B) part returns error because the called function returns error.
> 
> 	func () {
> 		...
> (A)		if (...)
> 			error("indicate error reason1")
> (A)		if (...)
> 			error("indicate error reason2")
> 		...
> 	}
> 
> 
> 	main() {
> 		...
> 		ret = func();
> (B)		if (ret < 0)
> 			error("func() error")
> 		...
> 	}

Hm, I think you're being too abstract for my comprehension, sorry about that.
Let me assume main() is the probe function, and func() is whatever function
that probe() calls. If my assumptions are correct, then:

- In (A), are we letting child functions print the reason of their own error? If so,
   I like the idea! In C we only return errors codes without a message, so the actual
   reason of, say, EINVAL is only known where the error was thrown. Outside of the
   context of the function an EINVAL just means "something was invalid". So yeah, I'd choose
   option (A).
- In (B), I think it's the approach already being used for simple_parse_of(), isn't it?
   You cannot know the reason of the error for sure, again because of error codes without
   a message being carried together. The best you can do here is thinking of a generic error
   message like I did.

Option (A) requires more work, of course.