From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f175.google.com (mail-pf1-f175.google.com [209.85.210.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AE833208B8; Thu, 19 Oct 2023 20:55:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lgoEW0S2" Received: by mail-pf1-f175.google.com with SMTP id d2e1a72fcca58-6b1d1099a84so149878b3a.1; Thu, 19 Oct 2023 13:55:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697748941; x=1698353741; darn=lists.linux.dev; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=PbXLmjJs4tDfsTjbZlYEpWsUipeZmvWuN4h1mPUkDJ0=; b=lgoEW0S2Zsw7bHjZJvUNPrxpb+s+NjtiEsFHFAMpz6sycHrCt3k9gmU95txy2GBf7a sPEj64H1mWaCcIs7VBBIUUCsJGnNpKHapbbmYK8s+sdOvgjQW7g1c44U8aYaDDON5bk+ nefabW6dKArjxKpN4CM9fEv9iPMlFMPGXgNvd/bwO1bhi1mnnTokIYfFDPcRm3kn+OI5 9R3wjp0KdD6IfUzQ90T9E3QqLqIc1BLoZ7kAp5sCMUMgJwch3jHEU16c+m4G0N4rl46b AsAGTDHZ3dtKyULbiycosd73LFfKf1aAGlYFSXTv4OMcL6OjxFggFqJFXyynZnTfaPhu cYHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697748941; x=1698353741; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=PbXLmjJs4tDfsTjbZlYEpWsUipeZmvWuN4h1mPUkDJ0=; b=goi5xaapeSbgEQKiVsf0ExE1BH8xPd+Y0AXZ27oadWSJBS9XWdfc9tA6ZLJOvKCDsH 83QN+a+dDPRLZdqvNVqmGoeoFzrmDV89W7+yzKiR+ytzwwuLsQQC8gxf9oEOftvfnu5w mWW/2cYYb14XlcZDdxnue9EueykY/bQV1I26W8af4+jIDQlfeZHal9atG3ysXJV9x393 z09LQMebhHOg/XL+s10LzGSKv3kNMEWk2NJBdPvRV1KcKDhHWaskGFGY9KXNHJlQB6Xy ztZP0pw97ZLCkT0kn2MDN+AOrdB+klkukRia8prsi6TIcMwXa/Xfcatmk+/b7LuxPX1t RlWQ== X-Gm-Message-State: AOJu0Yzjrr0+NBsrGaAj8CyRYWR2JON7BWeeI3IzcvIz67KrpgwtgyTr UW/PBE4BbN/Q+ZBRKbURTV7UQcGd7tM9mQ== X-Google-Smtp-Source: AGHT+IH7Gs2YuSv4uXr04F6lQ+npE/GpevyFYc7uZJwJ5aXaB5RN8oXxxiVdsBQ8DsgKo/v/cXQFWQ== X-Received: by 2002:a05:6a20:7486:b0:17a:fa76:805f with SMTP id p6-20020a056a20748600b0017afa76805fmr3692636pzd.23.1697748940668; Thu, 19 Oct 2023 13:55:40 -0700 (PDT) Received: from Negi ([68.181.16.134]) by smtp.gmail.com with ESMTPSA id l18-20020a17090aec1200b0027dc2af3a17sm1974326pjy.27.2023.10.19.13.55.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 19 Oct 2023 13:55:40 -0700 (PDT) Date: Thu, 19 Oct 2023 13:55:39 -0700 From: Soumya Negi To: Greg Kroah-Hartman Cc: Martyn Welch , Manohar Vanga , outreachy@lists.linux.dev, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev Subject: Re: [PATCH 1/2] staging: vme_user: Replace printk() with pr_*(),dev_*() Message-ID: <20231019205539.GA3017@Negi> References: <2023101823-unhidden-draw-d68c@gregkh> <20231018193855.GA32553@Negi> <2023101925-kudos-playful-7c5a@gregkh> <20231019190618.GA29750@Negi> <2023101941-poncho-disagree-8c77@gregkh> Precedence: bulk X-Mailing-List: linux-staging@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2023101941-poncho-disagree-8c77@gregkh> User-Agent: Mutt/1.9.4 (2018-02-28) On Thu, Oct 19, 2023 at 09:42:26PM +0200, Greg Kroah-Hartman wrote: > On Thu, Oct 19, 2023 at 12:06:18PM -0700, Soumya Negi wrote: > > On Thu, Oct 19, 2023 at 05:34:01PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, Oct 18, 2023 at 12:38:56PM -0700, Soumya Negi wrote: > > > > Hi Greg, > > > > > > > > On Wed, Oct 18, 2023 at 03:26:07PM +0200, Greg Kroah-Hartman wrote: > > > > > On Tue, Oct 17, 2023 at 09:36:32PM -0700, Soumya Negi wrote: > > > > > > vme.c uses printk() to log messages. To improve and standardize message > > > > > > formatting, use logging mechanisms pr_err()/pr_warn() and > > > > > > dev_err()/dev_warn() instead. Retain the printk log levels of the > > > > > > messages during replacement. > > > > > > > > > > > > Issue found by checkpatch.pl > > > > > > > > > > > > Signed-off-by: Soumya Negi > > > > > > --- > > > > > > drivers/staging/vme_user/vme.c | 175 ++++++++++++++++++--------------- > > > > > > 1 file changed, 94 insertions(+), 81 deletions(-) > > > > > > > > > > > > diff --git a/drivers/staging/vme_user/vme.c b/drivers/staging/vme_user/vme.c > > > > > > index 6519a7c994a0..e8c2c1e77b7d 100644 > > > > > > --- a/drivers/staging/vme_user/vme.c > > > > > > +++ b/drivers/staging/vme_user/vme.c > > > > > > @@ -9,6 +9,8 @@ > > > > > > * Copyright 2004 Motorola Inc. > > > > > > */ > > > > > > > > > > > > +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt > > > > > > > > > > No, this is a driver, as others have pointed out, always use dev_*() > > > > > calls instead. > > > > > > > > Some of the pr_ fns can be dev_, but I don't think all can. > > > > e.g. device NULL-check error messages > > > > > > I would argue that those are pointless and can be removed and also the > > > check is probably not needed either. > > > > Got it. The pr_() in find_bridge() can't be converted to dev_ so I'll remove > > the message entirely in another patch. > > > > I understand that the device-NULL checks should be done on the caller's side. > > Since empty devices would mean something went wrong, would it be better to > > put in an assertion(..WARN_ON) when removing the check? > > WARN_ON() means "I have no idea what can happen here so I give up", > which is not a good idea in kernel development. If that every hits, > then your machine will reboot as the huge majority of all Linux systems > in the world run with panic-on-warn enabled. > > If it is impossible for something to happen (i.e. you control all > callers) then just do not check for it. If it happens, you will get a > NULL-dereference which is the same as a WARN_ON() in a way. > > No new WARN_ON() should ever be added to the kernel, especially in a > driver. Handle the condition if it is possible to be hit. If it can > never be hit, don't even check it. > > thanks, > > greg k-h Hi Greg, Thank you for explaining in detail. I'll remove the device NULL-checks completely. Regards, Soumya