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]
Message-Id: <200802221030.32263.marc.pignat@hevs.ch>
Date:	Fri, 22 Feb 2008 10:30:31 +0100
From:	Marc Pignat <marc.pignat@...s.ch>
To:	David Brownell <david-b@...bell.net>
Cc:	anemo@....ocn.ne.jp, spi-devel-general@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org, hskinnemoen@...el.com
Subject: Re: [PATCH] atmel_spi: support zero length transfer

Hi Dave!

On Thursday 21 February 2008, David Brownell 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'...

...
> This *specific* usage might arguably belong in spi_device, since
> it's a delay required after chipselect goes active and before any
> bytes get transferred.  It's clearly not a per-transfer thing, and
> should also apply after a temporary mid-message chip deselect.
Ack, should be in spi_device (same remark for spi_transfer->delay_usec?).

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

Regards

Marc
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ