Dan Carpenter writes: > On Fri, May 19, 2017 at 03:03:31PM +0300, Jani Nikula wrote: >> On Fri, 19 May 2017, Colin King wrote: >> > From: Colin Ian King >> > >> > structure pl111_display_funcs can be made static as it does not need to be >> > in global scope. Fixes sparse warning: >> > >> > "warning: symbol 'pl111_display_funcs' was not declared. Should it >> > be static?" >> > >> > Fixes: bed41005e6174d ("drm/pl111: Initial drm/kms driver for pl111") >> >> The patch looks good and I appreciate what you're doing, but I question >> the usefulness of adding Fixes: tags for trivial stuff like this. I'd >> prefer Fixes: was reserved for actual fixes that should be backported to >> any kernels that have the commit being fixed. >> >> The same applies to many other patches you've sent recently. >> > > The Fixes tag is so so useful for everything. It should be included > in every bugfix. (I am the inventor of the Fixes tag). > > I told Colin to include the Fixes tag on everything. My review process > is partly "How was this bug introduced? How can we prevent it from > happening again? Who was the original author and have they reviewed the > proposed fix?" So I end up looking up the original commit anyway. It > helps me a lot to have the Fixes tag there. > > The Fixes tag is obviously useful for the stable people as well, but > that wasn't really the point. OK, that's definitely not how I've read the Documentation/process/submitting-patches.rst description of the Fixes tag, which talks about bugs found with git bisect and things that should go to -stable. I would not have considered what this patch is changing to be a bug.