Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757536AbcJXUmD (ORCPT ); Mon, 24 Oct 2016 16:42:03 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:53851 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756049AbcJXUl7 (ORCPT ); Mon, 24 Oct 2016 16:41:59 -0400 From: Arnd Bergmann To: "Deucher, Alexander" Cc: Alex Deucher , Baoyou Xie , 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 =?ISO-8859-1?Q?Wallm=E9nius?= , "Liu, Monk" , "Wang, Ken" , "Min, Frank" , "tang.qiang007@zte.com.cn" , "xie.baoyou@zte.com.cn" , LKML , Maling list - DRI developers , "han.fei@zte.com.cn" Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where possible Date: Mon, 24 Oct 2016 22:41:16 +0200 Message-ID: <42945045.1PbGIglsmX@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: References: <1477126582-2906-1-git-send-email-baoyou.xie@linaro.org> <3749845.re3cZTKYeA@wuerfel> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:GAdsc7NbpuXlIKctNDhwjz5et02BCCpOvJz5OZDwjgwgHq0W2Yn RFGf1e5zdmxHhDZbNcTTl59LQk/Xa3E3+eZg7emF/ueeZvAVcpwFt7jS404ztWNcs59O5cK U5PkOnme1GFCW1mtr0EaOMaJ8EN3Vr4iWfWUSoU9Ba1/llTJ4qnnHZDyiNCWOCZfEntDVVV Mlgcupc0V41IvFoZ4e3yA== X-UI-Out-Filterresults: notjunk:1;V01:K0:LLtBzUSFx64=:s0mH7FBEqa7W9gmcKN/JuS AaUD0nIX+s8sei4i17aRoQXCuC+8VU/IAUQxutQwIHCXaFIa/aMLDi8DVPGdm/zG7Qu3OnGQ3 47e5jG1rYD6ISEb5u7Gcd810+U+x5F0ajciTh4FFQmROYh8dCvN4INs0wRQpYNiVpJnYOckJu 0TBCZYzA8UnoDcX51FM8EQM5vuagUhX1Ej7U/a7N2zy1xq4PPQhP282tkTTBSyz2RDaNR8/gn pfuEpWoeMDbvhOi6aH3t2qFsuSZMR4COE1ViuMMofjiHTfrfzc8NajubIp0QP2L9vsAULdOXC jMPHI2LNlw/9fukoKPgjl+plrJkepr0IWZ/j9bfljR9d4iz4BmckroKwuzfddNFIN6FebtM+5 tUMF2x7KOpTa/U5FWuh+cyP81huCPu69OBpEPT/ET5hjb+e5+7khm94WpFFh2PbYXg0McOZCw vSw7D8SqXJu60Hy7pRb8t16H3pdUHTDKG72ADiVwUXu+BpvVrptHNbY2w7A6T6CE/LDTIvCH6 cay3qnwl/b4ZB5Z+DoQalsos0E0/Casr0cuQbvOHIIS+CWpUl8FBs+X0R8LREQcLVS7iIwZsl 2DwF6aX8eOJNMz3ID+NZrnGrdKPGhy47Ol+m8zjHhOLYJcdHDxtWFgF6Pz7ZogkzdkwEFANbs /TuqKLUofYeLYYWPQQWFpaRHO/9lACmU7nJG6XUeBRZRGF95Ostorw/uCoGDlgJs0sE3r8OZb HrL9mUbmxbqGiCCZ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1856 Lines: 32 On Monday, October 24, 2016 8:07:16 PM CEST Deucher, Alexander wrote: > > > > 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 > > > > > > 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--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. Ok, got it. Thanks for the detailed reply! Do you think it would be appropriate to include your drm-next-wip tree in linux-next? I think this is how a lot of the multi-level maintainer setups work as it give faster feedback about when things break. Arnd