On 25 October 2016 at 04:07, Deucher, Alexander <Alexander.Deucher at amd.com> wrote:
> > -----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 > OK, I see. Thanks for the detailed reply! -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20161025/43f3f22d/attachment-0001.html>
