From: Dan Carpenter <dan.carpenter@oracle.com>
To: chris <eklikeroomys@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
devel@driverdev.osuosl.org, Frank Mori Hess <fmh6jj@gmail.com>,
Ian Abbott <abbotti@mev.co.uk>,
Simo Koskinen <koskisoft@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: comedi: Improved readability of function comedi_nsamples_left.
Date: Tue, 12 Jun 2018 11:56:16 +0300 [thread overview]
Message-ID: <20180612085616.ukbpgtx7s4nxiekz@mwanda> (raw)
In-Reply-To: <20180610103001.GA7804@kerdev>
You haven't been sending the v2 and v3 patches in the right way.
Take a look through the email archive and see how this is normally done.
Also google it:
https://www.google.com/search?q=how+to+send+a+v2+patch
On Sun, Jun 10, 2018 at 12:30:01PM +0200, chris wrote:
> Hi Greg,
> I've added changelog text to the patch below. Appreciate your
> feedback!
> Regards,
> Chris Opperman
>
> >8----------------------------------------------------------------------8<
>
> Improved the readability of comedi_nsamples_left:
> a) Reduced nesting by using more return calls.
nit: return isn't a function so it can't be called.
> b) Separated variable declarations from code.
It was separate in the original code too.
> c) Using kernel integer types.
The original types were fine/better.
The rules are that we don't like uint32_t and the reason for not liking
it is that we looked through the kernel code and standardized on what
was most common...
Generally u32 and friends mean that the hardware or network protocol
specifies the number of bits. That's especially true for s32. If you
see code using s32 when it's not tied to a hardware spec then that's a
sign that the code is written by an insane person and it's a tricky
situation to deal with.
Some other reasons to use u32 is because it's shorter to type than
unsigned int and because of line lengths... I've sometimes done that.
But it's perhaps lazy.
>
> Signed-off-by: Chris Opperman <eklikeroomys@gmail.com>
> ---
> drivers/staging/comedi/drivers.c | 29 ++++++++++++++---------------
> 1 file changed, 14 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/staging/comedi/drivers.c b/drivers/staging/comedi/drivers.c
> index 9d73347..3207ae2 100644
> --- a/drivers/staging/comedi/drivers.c
> +++ b/drivers/staging/comedi/drivers.c
> @@ -468,26 +468,25 @@ EXPORT_SYMBOL_GPL(comedi_nscans_left);
> * Returns the number of samples remaining to complete the command, or the
> * specified expected number of samples (@nsamples), whichever is fewer.
> */
> -unsigned int comedi_nsamples_left(struct comedi_subdevice *s,
> - unsigned int nsamples)
> +u32 comedi_nsamples_left(struct comedi_subdevice *s, u32 nsamples)
> {
> struct comedi_async *async = s->async;
> struct comedi_cmd *cmd = &async->cmd;
> + u32 scans_left;
I would make scans_left an unsigned long long so that you can remove
the cast when you do the multiply.
> + u64 samples_left;
Nothing wrong with unsigned long long.
regards,
dan carpenter
next prev parent reply other threads:[~2018-06-12 8:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-09 14:23 Chris Opperman
2018-06-09 14:05 ` Greg Kroah-Hartman
2018-06-10 10:30 ` chris
2018-06-12 8:56 ` Dan Carpenter [this message]
2018-06-12 18:59 ` Chris Opperman
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=20180612085616.ukbpgtx7s4nxiekz@mwanda \
--to=dan.carpenter@oracle.com \
--cc=abbotti@mev.co.uk \
--cc=devel@driverdev.osuosl.org \
--cc=eklikeroomys@gmail.com \
--cc=fmh6jj@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=koskisoft@gmail.com \
--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 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®