From: Gerhard Sittig <gsi@denx.de>
To: Mark Brown <broonie@kernel.org>
Cc: "Ivan T. Ivanov" <iivanov@mm-sol.com>,
linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] spi: core: Validate lenght of the transfers in message
Date: Tue, 18 Feb 2014 20:37:47 +0100 [thread overview]
Message-ID: <20140218193747.GE4524@book.gsilab.sittig.org> (raw)
In-Reply-To: <20140218000938.GE2669@sirena.org.uk>
On Tue, Feb 18, 2014 at 09:09 +0900, Mark Brown wrote:
>
> On Sun, Feb 16, 2014 at 03:25:12PM +0100, Gerhard Sittig wrote:
> > On Sat, Feb 15, 2014 at 08:09 +0200, Ivan T. Ivanov wrote:
>
> > - the total length of the SPI transfer cannot be empty (which I'd
> > consider an optimization, not a violation, and may need a
> > separate discussion)
>
> We probably want to allow that for people doing fun stuff with cs_change
> though I'm not convinced anything doing that is actually a good idea.
>
> > - the total length of the SPI transfer must be such that each
> > "word" must be provided within a full 1/2/4 byte entity, with
> > padding bits if the bits-per-word is "odd"
>
> > Is this a misunderstanding on my side? A terminology thing? To
> > me, the "SPI transfer" is the total payload and may have any
> > arbitrary length. What you check for is a constraint on the
> > transfer's length derived from or based on the "word length"
> > ('word' in SPI context).
>
> > So the code may be appropriate, yet the description may need an
> > update, to not have the next person ask the same questions again.
>
> It seems fairly clear to me - if we're transferring 16 bit words we need
> the transfer to me a multiple of 16 bits and so on? The requirement for
> padding is unclear I have to say.
I meant "padding" in the sense that e.g. 12bit bits-per-word
require data to be provided or consumed in 16bit quantities (2
full bytes), 20bit bits-per-word require 4 bytes per SPI word.
Why not 3 bytes? I'd guess this is due to FIFO port width.
At least this is how I read the check which this patch
implements.
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
next prev parent reply other threads:[~2014-02-18 19:37 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-15 6:09 Ivan T. Ivanov
2014-02-16 14:25 ` Gerhard Sittig
2014-02-17 7:41 ` Ivan T. Ivanov
2014-02-18 0:09 ` Mark Brown
2014-02-18 19:37 ` Gerhard Sittig [this message]
2014-02-19 1:51 ` Mark Brown
2014-02-17 15:20 ` Ivan T. Ivanov
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=20140218193747.GE4524@book.gsilab.sittig.org \
--to=gsi@denx.de \
--cc=broonie@kernel.org \
--cc=iivanov@mm-sol.com \
--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
all inboxes | Powered by JetHome®