linux-kernel - Re: [PATCH] atmel_spi: support zero length transfer

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: <20080221192334.EE97A230A58@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date:	Thu, 21 Feb 2008 11:23:34 -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, hskinnemoen@...el.com
Subject: Re: [PATCH] atmel_spi: support zero length transfer

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

Passing zero bytes to get an inline delay at an exact spot in the
overall protocol message ... I don't see why not.  Better than
adding delay fields for every spot it might be needed by various
oddball devices, for sure!!

> IMHO, we should add a fied to the spi_transfer struct.

What would that do, exactly?

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.

And it would probably deserve a mode flag (sigh) unless someone
can update every master controller driver.

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