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 at linaro.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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
