linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ian Abbott <abbotti@mev.co.uk>
To: Mark Brown <broonie@kernel.org>
Cc: linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] spi: spidev: only use up TX/RX bounce buffer space when needed
Date: Mon, 16 Feb 2015 10:18:01 +0000	[thread overview]
Message-ID: <54E1C3D9.2010406@mev.co.uk> (raw)
In-Reply-To: <20150216041321.GM9110@finisterre.sirena.org.uk>

On 16/02/15 04:13, Mark Brown wrote:
> On Sun, Feb 15, 2015 at 10:30:22AM +0000, Ian Abbott wrote:
>> On 14/02/15 04:49, Mark Brown wrote:
>
>>> This is a bit hard to parse.  I think you're talking about buffers in
>>> spidev here but it's unclear and you've not described in what way you're
>>> changing the code and we do currently only seem to copy data when the
>>> user has asked for it.
>
>> Yes, I was talking about spidev. I did tag it in the subject line of the
>> commit message, though I'm sorry if the rest of it is difficult to parse.
>
> Right, but it's not clear if you mean that this is something to do with
> the device drivers for SPI controllers or spidev itself.

Okay, how about if I used the term "spidev device" to distinguish it 
from the lower-level SPI device?

>> Yes, the patch limits the total user-specified TX data and the total
>> user-specified RX data to the pre-allocated buffer size individually rather
>> than limiting the total sum of user RX and TX data.
>
> Your commit message needs to say this rather than requiring the user to
> reverse engineer it from the code - a key part of reviewing a code
> change is making sure that it does what the commit message says that it
> does to make sure that it is having the indended effect.

I thought it said that (somewhat clumsily) in the first paragraph.

>> The check against INT_MAX is there because a struct spi_ioc_transfer might
>> have rx_buf==NULL, tx_buf==NULL and len!=0, in which case it would no longer
>> use up space in either of the pre-allocated buffers so neither rx_total nor
>> tx_total would increase.  Checking the sum of the len fields against INT_MAX
>> prevents arithmetic overflow in the return value of the function.
>
> If that's what the code is supposed to do then someone reading the code
> needs to be able to tell that without too much effort, I'd not expect
> that to be possible as things are.  Maintainability is very important.

There was a whole paragraph about that in the commit message, but maybe 
it was too concise.

I'll have another attempt at the commit message to make it less concise 
and hopefully easier to follow!

-- 
-=( Ian Abbott @ MEV Ltd.    E-mail: <abbotti@mev.co.uk> )=-
-=(                          Web: http://www.mev.co.uk/  )=-

  reply	other threads:[~2015-02-16 10:18 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-12 12:13 [PATCH] spi: spidev: only use up TX/RX bounce buffer space when needed Ian Abbott
2015-02-14  4:49 ` Mark Brown
2015-02-15 10:30   ` Ian Abbott
2015-02-16  4:13     ` Mark Brown
2015-02-16 10:18       ` Ian Abbott [this message]
2015-02-16 13:23         ` Mark Brown
2015-02-16 14:33           ` Ian Abbott
2015-02-15 10:40   ` Ian Abbott

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=54E1C3D9.2010406@mev.co.uk \
    --to=abbotti@mev.co.uk \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@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;
as well as URLs for NNTP newsgroup(s).