All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michal Malý" <madcatxster@prifuk.cz>
To: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, elias.vds@gmail.com
Subject: Re: [RFC  v3] Add ff-memless-next
Date: Tue, 24 Dec 2013 03:11:57 +0100	[thread overview]
Message-ID: <16141479.Xuvegy6qFd@geidi-prime> (raw)
In-Reply-To: <1387844508.22671.73.camel@joe-AO722>

On Monday 23 of December 2013 16:21:48 you wrote:
> On Mon, 2013-12-23 at 23:46 +0100, Michal Malý wrote:
> > One case where uncombinable effects were mishandled was corrected. Rest of
> > the changes are just coding style fixes.
> 
> trivia:
> > diff --git a/drivers/input/ff-memless-next.c
> > b/drivers/input/ff-memless-next.c
> []
> 
> > +static __always_inline s32 mlnx_calculate_x_force(const s32 level,
> > +						  const u16 direction)
> 
> __always_inline is almost never warranted.
> gcc generally does the right thing.
I did some reading about __always_inline vs. plain inline and I ran into
some contradictory information about what is considered broken. Thanks
for letting me know...

Is there anything else that needs some reviewing?

WARNING: multiple messages have this Message-ID (diff)
From: "Michal Malý" <madcatxster@prifuk.cz>
To: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, elias.vds@gmail.com
Subject: Re: [RFC  v3] Add ff-memless-next
Date: Tue, 24 Dec 2013 03:11:57 +0100	[thread overview]
Message-ID: <16141479.Xuvegy6qFd@geidi-prime> (raw)
In-Reply-To: <1387844508.22671.73.camel@joe-AO722>

On Monday 23 of December 2013 16:21:48 you wrote:
> On Mon, 2013-12-23 at 23:46 +0100, Michal Malý wrote:
> > One case where uncombinable effects were mishandled was corrected. Rest of
> > the changes are just coding style fixes.
> 
> trivia:
> > diff --git a/drivers/input/ff-memless-next.c
> > b/drivers/input/ff-memless-next.c
> []
> 
> > +static __always_inline s32 mlnx_calculate_x_force(const s32 level,
> > +						  const u16 direction)
> 
> __always_inline is almost never warranted.
> gcc generally does the right thing.
I did some reading about __always_inline vs. plain inline and I ran into
some contradictory information about what is considered broken. Thanks
for letting me know...

Is there anything else that needs some reviewing?
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2013-12-24  2:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-23 22:46 [RFC v3] Add ff-memless-next Michal Malý
2013-12-23 22:46 ` Michal Malý
2013-12-24  0:21 ` Joe Perches
2013-12-24  0:21   ` Joe Perches
2013-12-24  2:11   ` Michal Malý [this message]
2013-12-24  2:11     ` Michal Malý
2013-12-24 19:38 ` Randy Dunlap
2013-12-24 19:38   ` Randy Dunlap

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=16141479.Xuvegy6qFd@geidi-prime \
    --to=madcatxster@prifuk.cz \
    --cc=elias.vds@gmail.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.