From: Emil Velikov Subject: Re: [PATCH 00/35] treewide trivial patches converting pr_warning to pr_warn Date: Thu, 23 Feb 2017 17:41:20 +0000 Message-ID: References: <1487870304.14159.29.camel@perches.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: "linux-fbdev@vger.kernel.org" , linux-ia64@vger.kernel.org, SH-Linux , Alexander Shishkin , ML nouveau , Linux-ALSA , dri-devel , "open list:VIRTIO GPU DRIVER" , "linux-ide@vger.kernel.org" , "linux-mtd@lists.infradead.org" , sparclinux@vger.kernel.org, drbd-dev@lists.linbit.com, Rob Herring , linux-omap , linux-scsi@vger.kernel.org, Richard Weinberger , tboot-devel@lists.sourceforge.net, amd-gfx mailing list , "linux-acpi@vger.kernel.org" , sfi-devel@simplefirmware.org, To: Joe Perches Return-path: In-Reply-To: <1487870304.14159.29.camel@perches.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org List-Id: linux-crypto.vger.kernel.org On 23 February 2017 at 17:18, Joe Perches wrote: > On Thu, 2017-02-23 at 09:28 -0600, Rob Herring wrote: >> On Fri, Feb 17, 2017 at 1:11 AM, Joe Perches wrote: >> > There are ~4300 uses of pr_warn and ~250 uses of the older >> > pr_warning in the kernel source tree. >> > >> > Make the use of pr_warn consistent across all kernel files. >> > >> > This excludes all files in tools/ as there is a separate >> > define pr_warning for that directory tree and pr_warn is >> > not used in tools/. >> > >> > Done with 'sed s/\bpr_warning\b/pr_warn/' and some emacsing. > [] >> Where's the removal of pr_warning so we don't have more sneak in? > > After all of these actually get applied, > and maybe a cycle or two later, one would > get sent. > By which point you'll get a few reincarnation of it. So you'll have to do the same exercise again :-( I guess the question is - are you expecting to get the series merged all together/via one tree ? If not, your plan is perfectly reasonable. Fwiw in the DRM subsystem, similar cleanups does purge the respective macros/other with the final commit. But there one can pull the lot in one go. Regards, Emil