SPI rework

Hi all!

I implement new SPI controller driver (for RT305XF) and found interest
problem: our current SPI implementation based on transfer data in
structure spi_command:
struct spi_command {
        void    *tx_cmd;
        uint32_t tx_cmd_sz;
        void    *rx_cmd;
        uint32_t rx_cmd_sz;
        void    *tx_data;
        uint32_t tx_data_sz;
        void    *rx_data;
        uint32_t rx_data_sz;
};
There is the problem 1, because all SPI requests I know use only two
transaction parts: 
	1 - write command (or read command if SPI slave)
	2 - read/write device data
so something like:
{
        void    *cmd;
        size_t 	cmd_sz;
        uint32_t 	cmd_flags;
#define	SPI_DIRECTION_READ	(0<<0)
#define	SPI_DIRECTION_WRITE	(1<<0)
        void    *data;
        size_t 	data_sz;
        uint32_t 	data_flags;
}; 
will be more accurate.

And the problem number 2: most controllers verify tx_cmd_sz ==
rx_cmd_sz, so seems `cmd` part must contain only request, and `data`
must contain only payload. 

And the problem number 3: SPI flash driver for example:
set buf[0] = 0x9f; /* SPI flash identify query */
then 
tx_cmd = buf;
tx_cmd_sz = rx_cmd_sz = 4;
And expect to receive device id in buf[1], buf[2], buf[3].

Soooo, how controller will decide which part of `buf` is a command, and
which part is a data? And again which part should be to write, which
to read? 

Somebody maybe ask me: Why you need it? Answer: because RT305XF spi
controller can't do bidirectional transfer, that controller can only
write or read.

Currently we have spi controllers for arm/at91 and mips/atheros (I have
also GPIO spi controller) and only one consumer for spibus -
dev/flash 

I "swear" to take care about mips/atheros, dev/flash and dev/spibus,
but seems will need some help from someone who work with Atmel's.

It will be very nice to have it discussed and done before 9.0.

Will wait for any comments and suggestions.

WBW
-- 
Aleksandr Rybalko <ray_at_ddteam.net>