[PATCH] drm/amd/powerplay: mark symbols static where possible
Deucher, Alexander
Alexander.Deucher at amd.com
Tue Oct 25 20:07:29 UTC 2016
> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Tuesday, October 25, 2016 4:15 AM
> To: Baoyou Xie
> Cc: Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy; Huang,
> JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang, Eric;
> Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils Wallménius; Liu,
> Monk; Wang, Ken; Min, Frank; dri-devel; Linux Kernel Mailing List;
> xie.baoyou at zte.com.cn; han.fei at zte.com.cn; tang.qiang007 at zte.com.cn
> Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> possible
>
> On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote:
> > On 25 October 2016 at 04:51, Arnd Bergmann <arnd at arndb.de> wrote:
> > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote:
> > > The function has no callers, so the easiest way would be to remove it
> > > entirely, but it's possible that there are plans to add users soon.
> > >
> > > It was assumed that this function will be used soon, so this patch remains
> > it.
> > if it still not be used in 4.10, then we can remove it.
> > is it right?
>
> There is no such rule in general, it's up to the maintainer and
> it depends on the specific reason for why the function ended up
> being unused in the first place.
>
> However, we can expect the maintainer to come up with some solution
> to address the warning. Possible options include:
>
> - calling the function from where it was meant to be used
> - removing the function
> - adding __maybe_unused
> - adding an #if 0
>
> I have not looked at this specific example and do not know
> which of them would be appropriate here. If you look at the
> output of 'git log -p
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c'
> you might find it out yourself.
This is mostly fallout from a big cleanup/re-org of the powerplay code in the 4.9. Rex said he was going to use these soon.
Alex
More information about the dri-devel
mailing list