linux-kernel - Re: [PATCH NAND v5] mtd: nand: Replace printk() with appropriate pr

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Feb 2018 18:39:11 +0100
From:   Boris Brezillon <boris.brezillon@...tlin.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Shreeya Patel <shreeya.patel23498@...il.com>,
        Boris Brezillon <boris.brezillon@...e-electrons.com>,
        Richard Weinberger <richard@....at>,
        David Woodhouse <dwmw2@...radead.org>,
        Brian Norris <computersforpeace@...il.com>,
        Marek Vasut <marek.vasut@...il.com>,
        Cyrille Pitchen <cyrille.pitchen@...ev4u.fr>,
        Maxim Levitsky <maximlevitsky@...il.com>,
        "open list:MEMORY TECHNOLOGY..." <linux-mtd@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ezequiel@...guardiasur.com.ar, outreachy-kernel@...glegroups.com
Subject: Re: [PATCH NAND v5] mtd: nand: Replace printk() with appropriate
 pr_*() macro

On Thu, 22 Feb 2018 19:08:29 +0200
Andy Shevchenko <andy.shevchenko@...il.com> wrote:

> On Thu, Feb 22, 2018 at 6:31 PM, Shreeya Patel
> <shreeya.patel23498@...il.com> wrote:
> > Using pr_<loglevel>() is more concise than
> > printk(KERN_<LOGLEVEL>).
> > Replace printks having a log level with the appropriate
> > pr_*() macros.
> > Define pr_fmt() and remove other additional macros from
> > the replaced printks.  
> 
> It makes sense to fix indentation, like in case similar to ' mm?"":""
> ',

Fix indentation if you change the line, why not...

> and fix the specifiers, when
> void *p is printed as 0x%08x or alike.

But specifier fixes should be done separately, and I'm not sure I
want to receive yet another bunch of cosmestic patches changing that, at
least not now.

-- 
Boris Brezillon, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com