LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
To: marc.pignat@hevs.ch
Cc: david-b@pacbell.net, spi-devel-general@lists.sourceforge.net,
	linux-kernel@vger.kernel.org, hskinnemoen@atmel.com
Subject: Re: [PATCH] atmel_spi: support zero length transfer
Date: Fri, 22 Feb 2008 23:15:10 +0900 (JST)	[thread overview]
Message-ID: <20080222.231510.56565462.anemo@mba.ocn.ne.jp> (raw)
In-Reply-To: <200802221030.32263.marc.pignat@hevs.ch>

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, 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).  Then the
behavior will be 'assert chip select and wait some time' or 'rejected
by the driver'.

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

---
Atsushi Nemoto

  reply	other threads:[~2008-02-22 14:15 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 [this message]
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
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=20080222.231510.56565462.anemo@mba.ocn.ne.jp \
    --to=anemo@mba.ocn.ne.jp \
    --cc=david-b@pacbell.net \
    --cc=hskinnemoen@atmel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.pignat@hevs.ch \
    --cc=spi-devel-general@lists.sourceforge.net \
    --subject='Re: [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).