[PATCH] drm/amd/powerplay: mark symbols static where possible

[Deucher, Alexander]

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd at arndb.de]
> Sent: Monday, October 24, 2016 3:49 PM
> To: Alex Deucher
> Cc: Baoyou Xie; 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; tang.qiang007 at zte.com.cn;
> xie.baoyou at zte.com.cn; LKML; Maling list - DRI developers;
> han.fei at zte.com.cn
> Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where
> possible
> 
> On Monday, October 24, 2016 12:36:52 PM CEST Alex Deucher wrote:
> > On Sat, Oct 22, 2016 at 4:56 AM, Baoyou Xie <baoyou.xie at linaro.org>
> wrote:
> > > We get a few warnings when building kernel with W=1:
> > >
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smumgr.c:162:5:
> warning: no previous prototype for 'fiji_setup_pwr_virus' [-Wmissing-
> prototypes]
> > > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/fiji_smc.c:2052:5:
> warning: no previous prototype for 'fiji_program_mem_timing_parameters'
> [-Wmissing-prototypes]
> > >
> drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/polaris10_smumgr.c:
> 175:5: warning: no previous prototype for 'polaris10_avfs_event_mgr' [-
> Wmissing-prototypes]
> > >
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/cz_hwmgr.c:1020:5:
> warning: no previous prototype for 'cz_tf_reset_acp_boot_level' [-
> Wmissing-prototypes]
> > >
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:92:26:
> warning: no previous prototype for 'cast_phw_smu7_power_state' [-
> Wmissing-prototypes]
> > > ....
> > >
> > > In fact, these functions are only used in the file in which they are
> > > declared and don't need a declaration, but can be made static.
> > > So this patch marks these functions with 'static'.
> > >
> > > Signed-off-by: Baoyou Xie <baoyou.xie at linaro.org>
> >
> > This was already applied the last time you sent it out.  Sorry if I
> > didn't mention that previously.
> 
> For some reason the patch hasn't made it into linux-next, so I can see
> why Baoyou was getting confused here. Can you clarify what the timeline
> is for the AMD DRM driver patches from between they get applied to the
> AMD tree to when they make it into linux-next?
> 

It came in late enough last cycle that it didn't make it into 4.9 (this is just a clean up not a critical bug fix), so I queued it for 4.10.  I try to reply when I apply a patch, but sometimes I miss one here and there.  Once Dave starts the drm-next tree for 4.10, it will be included in my pull request.  Pending -next patches are in my drm-next-<kernel version>-wip tree until I send Dave a formal request.

> I've occasionally had a hard time with DRM (and a few other subsystems)
> with bugfix patches trying to find out whether they got lost or
> whether they just haven't made it into -next but are in some other tree.
> 

For bug fixes we usually send Dave ~weekly pull requests for each -rc as necessary.  For -next stuff, each driver usually sends at least one, sometimes several pull requests for the next merge window.

Alex

> Baoyou, when you resend a patch, please try to list explicitly why
> you are resending it, when it was last sent, and what kind of reply
> you got (integrating any Ack, listing what changes you did, and
> if there are no other changes, why you think you have to resend it).
> 
> 	Arnd