[PATCH] drm/amd/powerplay: work around enum conversion warnings

[Arnd Bergmann]

On Mon, Jul 8, 2019 at 4:54 PM Nathan Chancellor
<natechancellor at gmail.com> wrote:
>
> Hi Arnd,
>
> On Mon, Jul 08, 2019 at 03:57:06PM +0200, Arnd Bergmann wrote:
> > A couple of calls to smu_get_current_clk_freq() and smu_force_clk_levels()
> > pass constants of the wrong type, leading to warnings with clang-8:
> >
> > drivers/gpu/drm/amd/amdgpu/../powerplay/vega20_ppt.c:995:39: error: implicit conversion from enumeration type 'PPCLK_e' to different enumeration type 'enum smu_clk_type' [-Werror,-Wenum-conversion]
> >                 ret = smu_get_current_clk_freq(smu, PPCLK_SOCCLK, &now);
> >                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~
> > drivers/gpu/drm/amd/amdgpu/../powerplay/inc/amdgpu_smu.h:775:82: note: expanded from macro 'smu_get_current_clk_freq'
> >         ((smu)->funcs->get_current_clk_freq? (smu)->funcs->get_current_clk_freq((smu), (clk_id), (value)) : 0)
> >
> > I could not figure out what the purpose is of mixing the types
> > like this and if it is written like this intentionally.
> > Assuming this is all correct, adding an explict case is an
> > easy way to shut up the warnings.
> >
> > Fixes: bc0fcffd36ba ("drm/amd/powerplay: Unify smu handle task function (v2)")
> > Fixes: 096761014227 ("drm/amd/powerplay: support sysfs to get socclk, fclk, dcefclk")
> > Signed-off-by: Arnd Bergmann <arnd at arndb.de>
>
> I sent a series last week for all of the clang warnings that were added
> in this driver recently.
>
> https://lore.kernel.org/lkml/20190704055217.45860-1-natechancellor@gmail.com/
>
> I think it is safe to use the CLK enums from the expected type (from
> what I could see from going down the code flow rabbit hole).
>
> https://lore.kernel.org/lkml/20190704055217.45860-4-natechancellor@gmail.com/
>
> https://lore.kernel.org/lkml/20190704055217.45860-7-natechancellor@gmail.com/

I tried that at first but concluded that it could not work because the constants
are different. Either it's currently broken and you patches fix the runtime
behavior, or it's currently correct and your patches break it.

        Arnd