> You might have noticed I also wrote in the same reply: > > "All of these pr_fmt uses are redundant as pr_err already does pr_fmt" I admit that I made another software development mistake there. - It might not matter much when a final fix could be to get rid of the three affected logging calls for example. > It is not just principle. > It is a fundamental for kernel patch submission. I hope that this view supports still the reordering for update steps after some discussion. > I am not an upstream path. > Greg KH generally serves that function here. > My suggestion would be to resend the entire patchset as V(n+1). I am curious if it would make sense to reduce the mail traffic a bit by finding out which software changes can be accepted already. Regards, Markus _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
