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 Also, there are portions of the driver where we have no access to any 'struct device' to feed into dev_. > Yes, that means that sometimes you do need to propagate the proper > device to the function, but that's ok, it's the correct solution here. Got it. In v2, I'll make pr_*() to dev_*() wherever possible. In most cases, the VME bridge device is accessible or if not we can get it using find_bridge(). Thanks, Soumya > thanks, > > greg k-h
