mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Colberg, Peter" <peter.colberg@intel.com>
To: "yilun.xu@linux.intel.com" <yilun.xu@linux.intel.com>
Cc: "Xu, Yilun" <yilun.xu@intel.com>,
	"linux-fpga@vger.kernel.org" <linux-fpga@vger.kernel.org>,
	"mdf@kernel.org" <mdf@kernel.org>,
	"andriy.shevchenko@linux.intel.com"
	<andriy.shevchenko@linux.intel.com>, "Wu, Hao" <hao.wu@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"russ.weight@linux.dev" <russ.weight@linux.dev>,
	"Pagani, Marco" <marpagan@redhat.com>,
	"Rix, Tom" <trix@redhat.com>,
	"matthew.gerlach@linux.intel.com"
	<matthew.gerlach@linux.intel.com>
Subject: Re: [PATCH RESEND] fpga: dfl: omit unneeded casts of u64 values for dev_dbg()
Date: Tue, 2 Apr 2024 19:24:00 +0000	[thread overview]
Message-ID: <1956417c03e8cf5b51c2edd3342b6c0b657ac0a1.camel@intel.com> (raw)
In-Reply-To: <Zgt7fA/Jfks/iKYi@yilunxu-OptiPlex-7050>

On Tue, 2024-04-02 at 11:29 +0800, Xu Yilun wrote:
> On Thu, Mar 28, 2024 at 08:04:29PM -0400, Peter Colberg wrote:
> > Omit unneeded casts of u64 values to unsigned long long for use with
> > printk() format specifier %llx. Unlike user space, the kernel defines
> > u64 as unsigned long long for all architectures; see commit 2a7930bd77fe
> > ("Documentation/printk-formats.txt: No casts needed for u64/s64").
> 
> The change is OK. But I suggest just delete the unnecessary dev_dbg()
> since now people normally don't want these "Hello, I'm here!" info.

Do you have specific commits in mind as a precedent that remove similar
occurrences? This patch was intended to be cosmetic, whereas dropping
dev_dbg() would introduce functional changes in a strict sense.

> > 
> > These changes are cosmetic only; no functional changes.
> > 
> > Suggested-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Peter Colberg <peter.colberg@intel.com>
> > ---
> > This is an unmodified resend of the second patch only from the series
> > "fpga: dfl: clean up string formatting for sysfs_emit() and dev_dbg()".
> 
> Why only pick this patch out of the series?

The two patches were cleanup patches but otherwise unrelated. I still
have to carry out the perf testing of the other patch as you suggested.

> 
> [...]
> 
> > diff --git a/drivers/fpga/dfl-fme-mgr.c b/drivers/fpga/dfl-fme-mgr.c
> > index ab228d8837a0..da3cb9c35de5 100644
> > --- a/drivers/fpga/dfl-fme-mgr.c
> > +++ b/drivers/fpga/dfl-fme-mgr.c
> > @@ -150,7 +150,7 @@ static int fme_mgr_write_init(struct fpga_manager *mgr,
> >  	priv->pr_error = fme_mgr_pr_error_handle(fme_pr);
> >  	if (priv->pr_error)
> >  		dev_dbg(dev, "previous PR error detected %llx\n",
> > -			(unsigned long long)priv->pr_error);
> > +			priv->pr_error);
> 
> I'm not sure if this is an real problem. Maybe we could keep it.
> 
> >  
> >  	dev_dbg(dev, "set PR port ID\n");
> >  
> > @@ -242,8 +242,7 @@ static int fme_mgr_write_complete(struct fpga_manager *mgr,
> >  	dev_dbg(dev, "PR operation complete, checking status\n");
> >  	priv->pr_error = fme_mgr_pr_error_handle(fme_pr);
> >  	if (priv->pr_error) {
> > -		dev_dbg(dev, "PR error detected %llx\n",
> > -			(unsigned long long)priv->pr_error);
> > +		dev_dbg(dev, "PR error detected %llx\n", priv->pr_error);
> 
> This is a real problem, is it? Change to dev_err()?

Thanks; yes, dev_err() seems reasonable and is consistent with the
earlier dev_err() after readq_poll_timeout().

Peter

> 
> Thanks,
> Yilun
> 
> >  		return -EIO;
> >  	}
> >  
> > -- 
> > 2.44.0
> > 
> > 


  reply	other threads:[~2024-04-02 19:24 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-29  0:04 Peter Colberg
2024-04-02  3:29 ` Xu Yilun
2024-04-02 19:24   ` Colberg, Peter [this message]
2024-04-18 21:30   ` Colberg, Peter
2024-04-19  9:05     ` Xu Yilun
2024-04-19 19:14       ` Colberg, Peter
2024-04-19 13:24     ` andriy.shevchenko
2024-04-19 19:19       ` Colberg, Peter
2024-04-22 11:08         ` andriy.shevchenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1956417c03e8cf5b51c2edd3342b6c0b657ac0a1.camel@intel.com \
    --to=peter.colberg@intel.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=hao.wu@intel.com \
    --cc=linux-fpga@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marpagan@redhat.com \
    --cc=matthew.gerlach@linux.intel.com \
    --cc=mdf@kernel.org \
    --cc=russ.weight@linux.dev \
    --cc=trix@redhat.com \
    --cc=yilun.xu@intel.com \
    --cc=yilun.xu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®