> I think pr_<level> is OK if reworking the code > to support dev_<level> is not easy. Thanks for this explanation. - It sounds more constructive than the previous short feedback "Not correct". >> 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. 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? >>> alloc_etherdev already does a dump_stack so the OOM isn't useful. >> Does this information indicate that this printk() (or pr_err()) call >> should be deleted? > > Markus, I don't know if it's your lack of English > comprehension or not, but it's fairly obvious from > my reply that this line should be deleted, I was unsure if this view fits to a consensus also by other developers. It might be that I can occasionally become picky to check if other contributors insist on the usage of a specific error message. > either in this patch or a follow-on. I would prefer another addition (or source code clean-up) later. Could it happen that so many error messages are update candidates (for deletion) so that no places remain where a pr_err() call would make sense in this software module? Regards, Markus -- 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
