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
> >
> >
next prev parent 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®