linux-kernel - Re: [spi-devel-general] [PATCH] atmel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 22 Feb 2008 10:58:52 -0800
From:	David Brownell <david-b@...bell.net>
To:	marc.pignat@...s.ch, anemo@....ocn.ne.jp
Cc:	spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [spi-devel-general] [PATCH] atmel_spi: support zero length 
 transfer

Quoth Atsushi Nemoto on Fri, 22 Feb 2008:
> On Fri, 22 Feb 2008 10:30:31 +0100, Marc Pignat <marc.pignat@...s.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/