linux-kernel - Re: [PATCH 15/34] mfd: sec: use dev_err

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <53e7fd763da3748dbc7a5205b4f93cdf9476aded.camel@linaro.org>
Date: Wed, 26 Mar 2025 09:42:44 +0000
From: André Draszik <andre.draszik@...aro.org>
To: Krzysztof Kozlowski <krzk@...nel.org>, Lee Jones <lee@...nel.org>, Rob
 Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>, Sylwester
 Nawrocki	 <s.nawrocki@...sung.com>, Chanwoo Choi <cw00.choi@...sung.com>,
 Alim Akhtar	 <alim.akhtar@...sung.com>, Michael Turquette
 <mturquette@...libre.com>,  Stephen Boyd <sboyd@...nel.org>, Russell King
 <linux@...linux.org.uk>, Catalin Marinas	 <catalin.marinas@....com>, Will
 Deacon <will@...nel.org>, Alexandre Belloni	 <alexandre.belloni@...tlin.com>
Cc: Peter Griffin <peter.griffin@...aro.org>, Tudor Ambarus
	 <tudor.ambarus@...aro.org>, Will McVicker <willmcvicker@...gle.com>, 
	kernel-team@...roid.com, linux-kernel@...r.kernel.org, 
	linux-samsung-soc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-rtc@...r.kernel.org
Subject: Re: [PATCH 15/34] mfd: sec: use dev_err_probe() where appropriate

On Wed, 2025-03-26 at 08:24 +0100, Krzysztof Kozlowski wrote:
> On 23/03/2025 23:39, André Draszik wrote:
> > dev_err_probe() exists to simplify code and harmonise error messages,
> > there's no reason not to use it here.
> > 
> > While at it, harmonise some error messages.
> > 
> > Signed-off-by: André Draszik <andre.draszik@...aro.org>
> Maybe such cleanups should be before you start moving the code and
> splitting modules into i2c/core/acpm.

Sure, I can re-order them. I didn't want the new PMIC to depend on
all that cleanup, as I believe that had been previous feedback (but
maybe I misremember :-), and also to avoid the new PMIC being blocked
on potentially contentious earlier cleanup patches, if any.


> Anyway:
> 
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>

Thanks!
Andre'