Re: [PATCH 0/6] [media] omap_vout: Adjustments for three function implementations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux