From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?B?SMKMYWF2YXJkIFNraW5uZW1vZW4=?= Date: Sun, 11 May 2008 22:56:55 +0200 Subject: [U-Boot-Users] [RFC/PATCH] SPI API improvements In-Reply-To: <200805091722.41084.vapier@gentoo.org> References: <1210346484-1313-1-git-send-email-haavard.skinnemoen@atmel.com> <200805091722.41084.vapier@gentoo.org> Message-ID: <48275D97.7020204@atmel.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Mike Frysinger wrote: > On Friday 09 May 2008, Haavard Skinnemoen wrote: >> This patch hasn't been tested on all the boards involved, so there are >> probably a few issues. For now, I'd like some comments on the new >> interface -- if it looks good, we should spend some additional effort >> to validate that it doesn't introduce any breakage. I could use some >> help with this. > > just a quick glance, but do we care about U-Boot being a SPI slave ? i only > noticed this as i was working on the Blackfin I2C driver recently and > realized that the I2C framework has defines for U-Boot to act as a slave. > not that the Blackfin driver even has any of the slave stuff implemented, i > just noticed it ;). I can't see much reason to add support for U-Boot acting as a SPI slave, and these patches certainly doesn't attempt to make that happen. If you're thinking of the new "struct spi_slave", that's a reference to the SPI slave we're talking to, i.e. whatever sits at the other end of the SPI bus. If someone else wants support for slave-mode SPI, maybe we should add it, but that should be an entirely separate set of patches. Haavard