On Sat, 2016-08-13 at 21:30 +0200, SF Markus Elfring wrote: > > > > I think pr_ is OK if reworking the code > > to support dev_ is not easy. > Thanks for this explanation. - It sounds more constructive than the previous short > feedback "Not correct". <frustration> How do you need your food prepared? Do others need to cut it for you to bite sized pieces? </frustration> 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" > > > Would you accept that another update will be appended to the discussed patch series? > > No. Patches should not knowingly introduce defects > > that are corrected in follow-on patches. > This view is fine in principle. It is not just principle. It is a fundamental for kernel patch submission. > I am just curious on the preferred sequence to fix the affected implementation details. > > 1. I imagine that my questionable update suggestion "[PATCH v2 08/10] staging: ks7010: > Replace three printk() calls by pr_err()" can be skipped and the remaining logging > calls will be improved somehow a bit later. > > Or: > > 2. Do you want a resend of this whole patch series? 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). > It might be that I can occasionally become picky to check if other contributors > insist on the usage of a specific error message. You can be prone to understatement. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
