> -----Original Message----- > From: Arnd Bergmann [mailto:arnd@xxxxxxxx] > 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@xxxxxxxxxx; > xie.baoyou@xxxxxxxxxx; LKML; Maling list - DRI developers; > han.fei@xxxxxxxxxx > 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@xxxxxxxxxx> > 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@xxxxxxxxxx> > > > > 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
