public inbox for kernel-janitors@vger.kernel.org
 help / color / mirror / Atom feed
From: Manuel Schoelling <manuel.schoelling@gmx.de>
To: Dongsheng Yang <dongsheng081251@gmail.com>
Cc: infinipath@intel.com, roland@kernel.org, sean.hefty@intel.com,
	hal.rosenstock@gmail.com, linux-rdma@vger.kernel.org,
	linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org
Subject: Re: [PATCH] ipath: use time_before()/_after()
Date: Sun, 25 May 2014 17:29:39 +0000	[thread overview]
Message-ID: <1401038979.7538.6.camel@schoellingm.dzne.de> (raw)
In-Reply-To: <CA+qeAOqUQ07YpFJjvFstUCDzt6-P_zBz-O1==OOYeBVOJ8Gppw@mail.gmail.com>

On So, 2014-05-25 at 22:17 +0800, Dongsheng Yang wrote:
> On Sun, May 25, 2014 at 9:26 PM, Manuel Schölling
> <manuel.schoelling@gmx.de> wrote:
> > To be future-proof and for better readability the time comparisons are
> > modified to use time_before/_after() instead of plain, error-prone math.
> >
> > Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de>
> > ---
> >  drivers/infiniband/hw/ipath/ipath_intr.c |    4 ++--
> >  drivers/infiniband/hw/ipath/ipath_sdma.c |    4 ++--
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/infiniband/hw/ipath/ipath_intr.c b/drivers/infiniband/hw/ipath/ipath_intr.c
> > index 26dfbc8..01ba792 100644
> > --- a/drivers/infiniband/hw/ipath/ipath_intr.c
> > +++ b/drivers/infiniband/hw/ipath/ipath_intr.c
> > @@ -70,7 +70,7 @@ void ipath_disarm_senderrbufs(struct ipath_devdata *dd)
> >         if (sbuf[0] || sbuf[1] || (piobcnt > 128 && (sbuf[2] || sbuf[3]))) {
> >                 int i;
> >                 if (ipath_debug & (__IPATH_PKTDBG|__IPATH_DBG) &&
> > -                       dd->ipath_lastcancel > jiffies) {
> > +                       time_after(dd->ipath_lastcancel, jiffies)) {
> 
> Why not time_is_after_jiffies()?
According to Joe Perches [1], time_after() is used much more often than
time_is_after_jiffies() and should be preferred.

[1] http://www.spinics.net/lists/netdev/msg283219.html

> 
> >                         __IPATH_DBG_WHICH(__IPATH_PKTDBG|__IPATH_DBG,
> >                                           "SendbufErrs %lx %lx", sbuf[0],
> >                                           sbuf[1]);
> > @@ -755,7 +755,7 @@ static int handle_errors(struct ipath_devdata *dd, ipath_err_t errs)
> >
> >         /* likely due to cancel; so suppress message unless verbose */
> >         if ((errs & (INFINIPATH_E_SPKTLEN | INFINIPATH_E_SPIOARMLAUNCH)) &&
> > -               dd->ipath_lastcancel > jiffies) {
> > +               time_after(dd->ipath_lastcancel, jiffies)) {
> >                 /* armlaunch takes precedence; it often causes both. */
> >                 ipath_cdbg(VERBOSE,
> >                         "Suppressed %s error (%llx) after sendbuf cancel\n",
> > diff --git a/drivers/infiniband/hw/ipath/ipath_sdma.c b/drivers/infiniband/hw/ipath/ipath_sdma.c
> > index 98ac18e..17a5177 100644
> > --- a/drivers/infiniband/hw/ipath/ipath_sdma.c
> > +++ b/drivers/infiniband/hw/ipath/ipath_sdma.c
> > @@ -247,7 +247,7 @@ static void sdma_abort_task(unsigned long opaque)
> >
> >         /* ipath_sdma_abort() is done, waiting for interrupt */
> >         if (status = IPATH_SDMA_ABORT_DISARMED) {
> > -               if (jiffies < dd->ipath_sdma_abort_intr_timeout)
> > +               if (time_before(jiffies, dd->ipath_sdma_abort_intr_timeout))
> >                         goto resched_noprint;
> >                 /* give up, intr got lost somewhere */
> >                 ipath_dbg("give up waiting for SDMADISABLED intr\n");
> > @@ -341,7 +341,7 @@ resched:
> >          * JAG - this is bad to just have default be a loop without
> >          * state change
> >          */
> > -       if (jiffies > dd->ipath_sdma_abort_jiffies) {
> > +       if (time_after(jiffies, dd->ipath_sdma_abort_jiffies)) {
> >                 ipath_dbg("looping with status 0x%08lx\n",
> >                           dd->ipath_sdma_status);
> >                 dd->ipath_sdma_abort_jiffies = jiffies + 5 * HZ;
> > --
> > 1.7.10.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/



      reply	other threads:[~2014-05-25 17:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-25 13:26 [PATCH] ipath: use time_before()/_after() Manuel Schölling
2014-05-25 14:17 ` Dongsheng Yang
2014-05-25 17:29   ` Manuel Schoelling [this message]

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=1401038979.7538.6.camel@schoellingm.dzne.de \
    --to=manuel.schoelling@gmx.de \
    --cc=dongsheng081251@gmail.com \
    --cc=hal.rosenstock@gmail.com \
    --cc=infinipath@intel.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=roland@kernel.org \
    --cc=sean.hefty@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