[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAF6AEGuOETKok05PeyLpC95bPBEw5=YoxB83B-cxmAjt6JVBcQ@mail.gmail.com>
Date: Sat, 20 May 2017 19:45:59 -0400
From: Rob Clark <robdclark@...il.com>
To: Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc: Daniel Vetter <daniel.vetter@...el.com>,
dri-devel <dri-devel@...ts.freedesktop.org>,
David Airlie <airlied@...ux.ie>,
Lucas Stach <l.stach@...gutronix.de>,
freedreno <freedreno@...ts.freedesktop.org>,
Benjamin Gaignard <benjamin.gaignard@...aro.org>,
Thierry Reding <thierry.reding@...il.com>,
Vincent Abriou <vincent.abriou@...com>,
Christian Gmeiner <christian.gmeiner@...il.com>,
Jonathan Hunter <jonathanh@...dia.com>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
Ben Skeggs <bskeggs@...hat.com>,
The etnaviv authors <etnaviv@...ts.freedesktop.org>,
Tomi Valkeinen <tomi.valkeinen@...com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-renesas-soc@...r.kernel.org, Marek Vasut <marex@...x.de>,
"nouveau@...ts.freedesktop.org" <nouveau@...ts.freedesktop.org>,
"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Russell King <linux+etnaviv@...linux.org.uk>
Subject: Re: [PATCH] drm: remove NULL pointer check for clk_disable_unprepare
On Sat, May 20, 2017 at 3:04 PM, Masahiro Yamada
<yamada.masahiro@...ionext.com> wrote:
> 2017-05-21 2:58 GMT+09:00 Masahiro Yamada <yamada.masahiro@...ionext.com>:
>> After long term efforts of fixing non-common clock implementations,
>> clk_disable() is a no-op for a NULL pointer input, and this is now
>> tree-wide consistent.
>>
>> All clock consumers can safely call clk_disable(_unprepare) without
>> NULL pointer check.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
>
>
> Sorry, I retract this patch.
>
> Krzysztof pointed out
> cleanups only for clk_disable_unprepare() will lose the code symmetry.
>
> NULL pointer checks for clk_prepare_enable() should be
> removed to keep the code symmetrical.
>
> This is possible for common-clock framework because
> clk_prepare_enable() is also a no-op for a NULL clk input.
> But it is not necessarily true for non-common clock implementations.
At least for drm/msm, upstream I think we can assume CCF.. I still
need to check for possible downstream kernels to which someone might
want to backport drm/msm.
It might be an idea to split this up per-driver, since at least for
some drivers it might be safe to assume CCF (or non-CCF clk driver
that behaves the same)
BR,
-R
>
> --
> Best Regards
> Masahiro Yamada
Powered by blists - more mailing lists