LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: marc.pignat@hevs.ch, anemo@mba.ocn.ne.jp
Cc: spi-devel-general@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [spi-devel-general] [PATCH] atmel_spi: support zero length  transfer
Date: Fri, 22 Feb 2008 10:58:52 -0800	[thread overview]
Message-ID: <20080222185852.5863D28E371@adsl-69-226-248-13.dsl.pltn13.pacbell.net> (raw)
In-Reply-To: <20080222.231510.56565462.anemo@mba.ocn.ne.jp>

Quoth Atsushi Nemoto on Fri, 22 Feb 2008:
> On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <marc.pignat@hevs.ch> wrote:
> > > > David, do you think writing 0 bytes is a valid use of this API?
> > > 
> > > Just a zero byte transfer ... no, though it depends what you mean
> > > by "valid".  (I'm not sure I'd expect all controller drivers to
> > > reject such requests.)  That has no effect on bits-on-the-wire,
> > > and would make trouble for various DMA engines.
> >
> > So, the behaviour is undefined,

Not what I said.  To repeat:  it makes sense to pass zero bytes
in at least one case, which is not "just" a zero byte transfer.

And in a practical sense, until we have some kind of regression
testing scheme -- with some kind of "golden device" -- it's not
very sensible for any SPI Protocol Driver to expect that all SPI
Master Controller Drivers act consistently in such cases.


> >	something between 'crash my dma engine',
> > 'assert chip select and wait some time', or 'do_nothing'...
>
> If the driver could not handle zero length transfer, then the driver
> should reject it (just like unsupported transfer mode).

Exactly.  Behaviors like "crash my DMA engine" are clearly "invalid",
in *ALL* cases.  Bugs to get fixed as soon as they're noticed.


>	Then the
> behavior will be 'assert chip select and wait some time' or 'rejected
> by the driver'.

The "wait" mode is what started this thread -- not "just" a zero
byte transfer, but one which does real work.

For "just" a zero byte transfer, I see two main implementation
options ... with no compelling reason to force either one.

  - "ignored" ... the implementation sibling of "wait"
  - "rejected" ... more work

The argument for "rejected" would seem to be only that this is a
case of "protocol drivers should not do this".  But if they don't,
then the difference doesn't matter.


> > > And it would probably deserve a mode flag (sigh) unless someone
> > > can update every master controller driver.
> >
> > Supporting the zero-len-write means checking and perhpaps updating
> > each driver for the benefit of having an unknown length delay.
> > 
> > We should add the delay field in the spi_device, but this means more work.
> > 
> > Is this kind of device so common that we need to do all that work? or can we
> > leave it as is (verified to work only with atmel_spi)?
>
> I think my case is not so common.  But if the driver could support
> zero length transfer easily, there is no reason to reject it.
>
> And if nobody wanted to support zero length transfer on that driver,
> it would be no reason to update it ;)

So long as the controller driver doesn't misbehave, I can't see any
reason to worry about this behavior.

- Dave


  parent reply	other threads:[~2008-02-22 18:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-20 15:54 Atsushi Nemoto
2008-02-20 17:55 ` Marc Pignat
2008-02-21  1:52   ` Atsushi Nemoto
2008-02-21  9:26     ` Marc Pignat
2008-02-21 19:23       ` David Brownell
2008-02-22  9:30         ` Marc Pignat
2008-02-22 14:15           ` Atsushi Nemoto
2008-02-22 14:28             ` [spi-devel-general] " Ned Forrester
2008-02-22 19:06               ` David Brownell
2008-02-22 19:52                 ` Ned Forrester
2008-02-22 18:58             ` David Brownell [this message]
2008-02-23  2:55           ` David Brownell
2008-02-25  8:15             ` Marc Pignat
2008-02-22 14:07         ` [spi-devel-general] " Ned Forrester
2008-02-22 19:02           ` David Brownell
2008-02-22 19:36             ` Ned Forrester
2008-02-23  2:37               ` David Brownell
2008-02-25  0:25               ` Atsushi Nemoto

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=20080222185852.5863D28E371@adsl-69-226-248-13.dsl.pltn13.pacbell.net \
    --to=david-b@pacbell.net \
    --cc=anemo@mba.ocn.ne.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.pignat@hevs.ch \
    --cc=spi-devel-general@lists.sourceforge.net \
    --subject='Re: [spi-devel-general] [PATCH] atmel_spi: support zero length  transfer' \
    /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

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).