Le 26/02/2017 à 16:25, Rob Clark a écrit :
On Sun, Feb 26, 2017 at 7:10 AM, Christophe JAILLET
<christophe.jaillet@xxxxxxxxxx> wrote:
If a 'clk_prepare_enable()' fails, then we need to disable_unprepare the
clk already handled.
With the current implemenatation, we try to do that on the clk that has
triggered the error, which is a no-op and leave msm_host->bus_clks[0]
untouched.
Count forward in order to fix it and be more future proof.
Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
---
v2: change the for loop from a backward to a forward one, to ease reading.
fwiw, I prefer your v1, for reasons discussed on a similar patch
fixing the same issue:
https://lists.freedesktop.org/archives/dri-devel/2017-February/133097.html
(although your v1 is a better solution than the original, since we
probably don't want to clk_disable_unprepare() the clk that failed to
enable.)
BR,
-R
Argh, 2 times in the same week that I post something already proposed by
Dan.
Sorry for the noise. I should be more careful.
Thanks for the link and for explanation.
Best regards,
CJ
--
To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
