[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <vhhxtsspywvuzkfgbn52hysghd6tdxhk32wv3wcnlqwhskto3f@h2bbhek3s4s3>
Date: Thu, 26 Jun 2025 00:10:26 +0200
From: Andi Shyti <andi.shyti@...nel.org>
To: Christophe JAILLET <christophe.jaillet@...adoo.fr>
Cc: Aaro Koskinen <aaro.koskinen@....fi>,
Andreas Kemnade <andreas@...nade.info>, Kevin Hilman <khilman@...libre.com>,
Roger Quadros <rogerq@...nel.org>, Tony Lindgren <tony@...mide.com>,
Janusz Krzysztofik <jmkrzyszt@...il.com>, Vignesh R <vigneshr@...com>,
Jayesh Choudhary <j-choudhary@...com>, linux-kernel@...r.kernel.org, kernel-janitors@...r.kernel.org,
linux-omap@...r.kernel.org, linux-i2c@...r.kernel.org
Subject: Re: [PATCH] i2c: omap: Fix an error handling path in omap_i2c_probe()
Hi Christophe,
On Sat, Jun 14, 2025 at 04:59:26PM +0200, Christophe JAILLET wrote:
> If an error occurs after calling mux_state_select(), mux_state_deselect()
> should be called as already done in the remove function.
>
> Fixes: b6ef830c60b6 ("i2c: omap: Add support for setting mux")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@...adoo.fr>
merged to i2c/i2c-host-fixes. Thanks!
> ---
> I'm not 100% sure of the error handling path.
>
> Should pm_runtime_dont_use_autosuspend() be called after the err_disable_pm
> label? (to match the calling order)
Yes, I think you are right here.
> Also, should errors from omap_i2c_init() be handled?
Yes, if it fails it should be handled.
Thanks for the two reports. Do you have time to fix them or
can I go ahead and do it?
Thanks,
Andi
Powered by blists - more mailing lists