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:tbh I think all drm drivers should be in linux-next. The early head-ups
Ok, got it. Thanks for the detailed reply!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.For some reason the patch hasn't made it into linux-next, so I can seeIn fact, these functions are only used in the file in which they areThis was already applied the last time you sent it out. Sorry if I
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>
didn't mention that previously.
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?
I've occasionally had a hard time with DRM (and a few other subsystems)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.
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.
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.
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