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 <soumya.negi97@xxxxxxxxx> > > > > > > --- > > > > > > 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
