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@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.
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.
Christian.
-Daniel
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
