On Mon, Feb 27, 2017 at 11:18 AM, Jani Nikula <jani.nik...@linux.intel.com> wrote: > On Sun, 26 Feb 2017, Daniel Vetter <dan...@ffwll.ch> wrote: >> On Thu, Feb 16, 2017 at 02:27:08PM +0200, Jani Nikula wrote: >>> On Thu, 16 Feb 2017, Rob Clark <robdcl...@gmail.com> wrote: >>> > On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter <dan.carpen...@oracle.com> >>> > wrote: >>> >> We're off by one here. We free something that wasn't allocated and we >>> >> don't free msm_host->bus_clks. >>> >> >>> >> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list") >>> >> Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> >>> > >>> > Thanks >>> > >>> > Reviewed-by: Rob Clark <robdcl...@gmail.com> >>> >>> And for good measure, >>> >>> Reviewed-by: Jani Nikula <jani.nik...@intel.com> >> >> So 2 r-b from maintainers, no one said he'll apply. This isn't really >> great coordination :-) Note that drm-misc-next is always open, so you >> could always smash it in there, irrespective of merge window state. hint, >> hint ... > > Admittedly I shied away from touching drm/msm.
Well that's kinda my point, we have a pile of maintainers who could push this, which means if no one says they do, the patch will likely get lost. Especially if the main maintainer (Rob here) smashes an r-b onto a patch it's super confusing, at least to me. I guess this is a downside to having lots of committers, and I started to stumble over this in a bunch of places. I think as a rule we should always state when we plan to or have merged a patch, and if it's just an r-b assume it's lost ... At least that's how I deal with core refactorings touching drivers, otherwise we'd probably never get them all landed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Freedreno mailing list Freedreno@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/freedreno