>>> These two unnecessary NULL checks were tracked in the call >>> chain as never NULL, … >> >> I find this wording too generic. >> How do you think about to point the function(s) out exactly >> which call the discussed function implementations? > > It's on the code Markus, no need to put this on commit message. I would prefer a safer explanation there. > Commit messages aren't meant to describe what code changes were done, > just to specify why and how (in a theoretical way). Is this issue easier to understand when the source code place will be explicitly mentioned from where these functions get always (!) a non-null pointer passed? >>> No functional changes are intended. >> >> Did we agree already that such an information could be questionable? >> https://lkml.kernel.org/r/<e456697b-c412-4de6-a1dd-95ec4a219c68@xxxxxxxxxxxxxxxxxx> >> >> Is another approach needed to achieve the desired consensus? > > > I didn't agree with this - I mean, no functional change was intended, > it's a fact. How much is the deletion of two sanity checks a functional adjustment? > Do we agree that the NULL checks were useless? If yes Two maintainers expressed such a view. > (and we do, since it was your suggestion), I dared to ask once for this case in this software design direction. https://lkml.org/lkml/2017/11/29/906 > how removing them will change the function of adapter/driver? Such an adjustment should result in a bit smaller object code for this software module so that you might get nicer run time characteristics. By the way: * Is there a need to include also the general Linux kernel mailing list as a recipient for this update suggestion? * Is a cover letter also useful for a patch series with only two update steps? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-serial" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
