On 09/28/2015 06:18 AM, Sudip Mukherjee wrote:
On Sat, Sep 26, 2015 at 12:45:46PM -0500, Larry Finger wrote:
On 09/26/2015 11:49 AM, Punit Vara wrote:
This patch is to the rtl871x_ioctl_linux.c that fixes up following
warning reported by checkpatch.pl :
- Comparisons should place the constant on the right side of the test
Signed-off-by: Punit Vara <punitvara@xxxxxxxxx>
This warning is crap. WTF difference does it make???? The compiler
does not care, and any reader with any piece of a brain is not going
to be confused!
This patch and all others like it are just meaningless source churning!
This author has made such a royal mess of his patches that I
recommend that ALL of them be dropped. In addition, we should
continue to drop his changes until he learns how to use git to
generate N/M patches, and until he reads the documentation on patch
submission.
Excuse me for my ignorance, but I still can not see what was wrong with
his patch. checkpatch is giving warning and he has fixed it. As far as
sending in series is concerned, he is a newbie and after telling him how
to generate patches in series he has learnt that. I have already told
him that his patches might be dropped as they are not in series and he
is ready to resend in series as soon as Greg confirms that they are
dropped. And as long as the driver is in staging there will be source
churning, isn't it?
If i remember correctly I was told that for a driver to be moved out of
staging the primary thing is that all checkpatch warnings needs to fixed.
So if this driver has to move out of staging someday then these warnings
also has to be fixed by someone.
The primary requirement for moving a driver out of staging is that it use
mac80211. No amount of cosmetic fixing will ever make that change for rtl8712u!
In my opinion, not ALL checkpatch warnings ever need to be heeded.Can you tell
me why
/**
* This is a comment
*/
is superior to
/*
This is a comment also
*/
The difference is not significant, yet checkpatch treats it as though the source
was horribly flawed. Similarly, satisfying the 80-character requirement can
leave the code horribly unreadable.
My main complaint is that the OP submitted dozens of patches with similar
subjects, yet gave no indication is any of these were resubmissions, and
completely failed to utilize the patch series mechanism of git. This behavior
makes life difficult for both the maintainer and the reviewer.
Larry
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel