> >> Given timing I suspect that by the we have reviewed these will be too > >late in this cycle so will hit in the merge window plus stable. > >> > >> Also some of these are cleanups rather than fixes so should normally > >be separate from fixes and applied after them as they are not > >> Stable material. > > > >I tried to keep 5/5 as small as possible so I factor individual and > >separate changes as good as possible as long as the drivers remained > >functional. That means 1-4 are mostly pre-work for 5/5 and that makes > >5/5 depends on them. > > > >Tagging 5/5 stable I would prefer to take 1-4, too to keep the backport > >effort small. The clash due to the continues mode which is v3.13 is > >probably small. This said, I think it is the best to backport it stable > >if someone asks for it (unless the majority here thinks otherwise). > > > >Are you saying this is too late for v3.13 or v3.14-rc1? > > > >Sebastian > > Too late for 3.13. Probably fine for next merge window if reviews are all good or as a > fix post 3.14-rc1 of it misses the cutoff for the merge window. I think this set should go in via -next. So it will hit the v3.14 merge window. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
