Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S941565AbcJYGlu (ORCPT ); Tue, 25 Oct 2016 02:41:50 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:39954 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753157AbcJYGlt (ORCPT ); Tue, 25 Oct 2016 02:41:49 -0400 Date: Tue, 25 Oct 2016 08:41:44 +0200 From: Daniel Vetter To: Arnd Bergmann Cc: "Deucher, Alexander" , "Zhou, Jammy" , Maling list - DRI developers , "Huang, Ray" , "Huang, JinHuiEric" , "Cui, Flora" , "StDenis, Tom" , Baoyou Xie , "tang.qiang007@zte.com.cn" , "Prosyak, Vitaly" , "Min, Frank" , Dan Carpenter , "xie.baoyou@zte.com.cn" , "han.fei@zte.com.cn" , "Liu, Monk" , Nils =?iso-8859-1?Q?Wallm=E9nius?= , "Yang, Eric" , "Zhu, Rex" , LKML , "Yang, Young" , "Wang, Ken" , "Edward O'Callaghan" Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where possible Message-ID: <20161025064144.sl7rmeixwswd2uze@phenom.ffwll.local> Mail-Followup-To: Arnd Bergmann , "Deucher, Alexander" , "Zhou, Jammy" , Maling list - DRI developers , "Huang, Ray" , "Huang, JinHuiEric" , "Cui, Flora" , "StDenis, Tom" , Baoyou Xie , "tang.qiang007@zte.com.cn" , "Prosyak, Vitaly" , "Min, Frank" , Dan Carpenter , "xie.baoyou@zte.com.cn" , "han.fei@zte.com.cn" , "Liu, Monk" , Nils =?iso-8859-1?Q?Wallm=E9nius?= , "Yang, Eric" , "Zhu, Rex" , LKML , "Yang, Young" , "Wang, Ken" , Edward O'Callaghan References: <1477126582-2906-1-git-send-email-baoyou.xie@linaro.org> <3749845.re3cZTKYeA@wuerfel> <42945045.1PbGIglsmX@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42945045.1PbGIglsmX@wuerfel> X-Operating-System: Linux phenom 4.6.0-1-amd64 User-Agent: NeoMutt/20161014 (1.7.1) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2269 Lines: 40 On Mon, Oct 24, 2016 at 10:41:16PM +0200, Arnd Bergmann wrote: > 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. tbh I think all drm drivers should be in linux-next. The early head-ups about conflicts are really useful. Same for nouveau, but given that nouveau is developed in a userspace git repo that's harder to pull off. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch