From mboxrd@z Thu Jan 1 00:00:00 1970 From: Sebastian Andrzej Siewior Subject: [RFC] SPI transfer with (count % bpw >> 3) != 0 Date: Fri, 16 Oct 2009 22:37:08 +0200 Message-ID: <20091016203708.GB9552@Chamillionaire.breakpoint.cc> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: David Brownell Return-path: Content-Disposition: inline List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: spi-devel-general-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: linux-spi.vger.kernel.org Just stumbled over this one: for instance bpw = 16 and len = 1. I've found a few possible results: - no transfer at all and return 0 (spi_gpio) - no transfer at all and return with -EINVAL (spi_mpc8xxx) - transfer two bytes and overwrite one probably unallocated byte in the read case. Return 1 (amba-pl022) - write until an exception stops it (orion_spi) Variant three and four is obviously wrong and should be fixed. However I'm torn between variant one and two as the correct way to deal with this. This problem is not just an in-kernel thing but also exposed to user space via spidev. The man page for read() and write() says that the function might return less than the number of requested bytes if more data is not available. In this case there is more data available but due to an programming error (?) we don't get anything. From that angle -EINVAL sounds good. David? Sebastian ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference