Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751525AbbHQSG5 (ORCPT ); Mon, 17 Aug 2015 14:06:57 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:33922 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbbHQSG4 (ORCPT ); Mon, 17 Aug 2015 14:06:56 -0400 Date: Mon, 17 Aug 2015 21:06:57 +0300 From: Dan Carpenter To: =?iso-8859-1?Q?Rapha=EBl?= Beamonte Cc: Johnny Kim , Rachel Kim , Dean Lee , Chris Park , Greg Kroah-Hartman , linux-wireless@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/5] staging: wilc1000: use pr_* instead of printk Message-ID: <20150817180657.GF5610@mwanda> References: <4feb986f253ce20790cafabbf2262c0cc1f2be92.1439827537.git.raphael.beamonte@gmail.com> <20150817174707.GE5610@mwanda> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1871 Lines: 42 On Mon, Aug 17, 2015 at 01:59:44PM -0400, Rapha?l Beamonte wrote: > 2015-08-17 13:47 GMT-04:00 Dan Carpenter : > >> - printk("[Sendconfigpkt]Get Timed out\n"); > >> + pr_debug("[Sendconfigpkt]Get Timed out\n"); > > > > > > Possibly pr_err()? > > Yep. My mistake. I'll do the same for Set Timed Out also! > > >> - printk("DBG [%s: %d]", __func__, __LINE__); \ > >> - printk(__VA_ARGS__); \ > >> + pr_debug("DBG [%s: %d]", __func__, __LINE__); \ > >> + pr_debug(__VA_ARGS__); \ > > > > This is a behavior change, I think. pr_debug() needs to be turned on? > > Yes... I didn't pay attention to that! pr_debug needs -DDEBUG in the makefile. > Should I use pr_info here? Or just acknowledge the behavior change for > the moment, > as the next aim is probably, as you said, to remove all the local > debug code? (it is > actually part of the TODO of this driver... So I could just work on that next.) I would probably just do the rest and leave this part as-is since you're planning to redo it all anyway. I guess just do stuff which is obvious and hopefully more and more stuff will become obvious as you go along. This is a lazy answer but I don't want to think about this driver very hard... :P Also always try to order your patches from least controversial to most controversial. It makes it easier to redo things or sometimes Greg applies the first part of a patch series. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/