Hi Markus, On 09/24/2017 12:20 PM, SF Markus Elfring wrote: > From: Markus Elfring <elfring@xxxxxxxxxxxxxxxxxxxxx> > Date: Sun, 24 Sep 2017 12:06:54 +0200 > > A few update suggestions were taken into account > from static source code analysis. > > Markus Elfring (6): > Delete an error message for a failed memory allocation in omap_vout_create_video_devices() > Improve a size determination in two functions > Adjust a null pointer check in two functions > Fix a possible null pointer dereference in omap_vout_open() > Delete an unnecessary variable initialisation in omap_vout_open() > Delete two unnecessary variable initialisations in omap_vout_probe() > > drivers/media/platform/omap/omap_vout.c | 23 ++++++++++------------- > 1 file changed, 10 insertions(+), 13 deletions(-) > While we do not mind cleanup patches, the way you post them (one fix per file) is really annoying and takes us too much time to review. I'll take the "Fix a possible null pointer" patch since it is an actual bug fix, but will reject the others, not just this driver but all of them that are currently pending in our patchwork (https://patchwork.linuxtv.org). Feel free to repost, but only if you organize the patch as either fixing the same type of issue for a whole subdirectory (media/usb, media/pci, etc) or fixing all issues for a single driver. Actual bug fixes (like the null pointer patch in this series) can still be posted as separate patches, but cleanups shouldn't. So in this particular case I would expect two omap_vout patches: one for the bug fix, one for the cleanups. Just so you know, I'll reject any future patch series that do not follow these rules. Just use common sense when posting these things in the future. I would also suggest that your time might be spent more productively if you would work on some more useful projects. There is more than enough to do. However, that's up to you. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
