linux-kernel - Re: [PATCH] drm/amd/powerplay: mark symbols static where possible

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 25 Oct 2016 10:11:45 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Christian König <deathsimple@...afone.de>
Cc:     Arnd Bergmann <arnd@...db.de>,
        "Deucher, Alexander" <Alexander.Deucher@....com>,
        "Zhou, Jammy" <Jammy.Zhou@....com>,
        Maling list - DRI developers 
        <dri-devel@...ts.freedesktop.org>,
        "Huang, Ray" <Ray.Huang@....com>,
        "Huang, JinHuiEric" <JinHuiEric.Huang@....com>,
        "Cui, Flora" <Flora.Cui@....com>,
        "StDenis, Tom" <Tom.StDenis@....com>,
        Baoyou Xie <baoyou.xie@...aro.org>,
        "tang.qiang007@....com.cn" <tang.qiang007@....com.cn>,
        "Prosyak, Vitaly" <Vitaly.Prosyak@....com>,
        "Min, Frank" <Frank.Min@....com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        "xie.baoyou@....com.cn" <xie.baoyou@....com.cn>,
        "han.fei@....com.cn" <han.fei@....com.cn>,
        "Liu, Monk" <Monk.Liu@....com>,
        Nils Wallménius <nils.wallmenius@...il.com>,
        "Yang, Eric" <Eric.Yang2@....com>, "Zhu, Rex" <Rex.Zhu@....com>,
        LKML <linux-kernel@...r.kernel.org>,
        "Yang, Young" <Young.Yang@....com>, "Wang, Ken" <Ken.Wang@....com>,
        Edward O'Callaghan <funfunctor@...klore1984.net>
Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where possible

On Tue, Oct 25, 2016 at 09:09:01AM +0200, Christian König wrote:
> Am 25.10.2016 um 08:41 schrieb Daniel Vetter:
> > 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 <baoyou.xie@...aro.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.
> > > 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.
> 
> Mhm, in general I agree that seeing merge conflicts and getting a bit more
> testing earlier would be a good idea.
> 
> But Alex has the practice of regenerating his -wip branches multiple times.
> That is usually not a problem because the only one occasionally basing work
> on that branch is me, but it would be if you start to merge it somewhere.

linux-next is fine with rebasing branches. drm-intel is in there since
years, and we've only very recently stopped rebasing our main branch. What
Alex might need to change is switching the branch name for each kernel
release, i.e. amd-wip instead of amd-4.10-wip. And be more careful with
making sure only stuff heading for the current merge window shows up in
there.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch