Message-ID: <43A95713.6020405@ru.mvista.com>
Date: Wed, 21 Dec 2005 16:22:27 +0300
From: Vitaly Wool <vwool@ru.mvista.com>
User-Agent: Mozilla Thunderbird 1.0 (X11/20041206)
MIME-Version: 1.0
To: David Brownell <david-b@pacbell.net>
CC: linux-kernel@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: [PATCH/RFC] SPI core: turn transfers to be linked list
References: <43A480C0.9080201@ru.mvista.com> <200512181240.46841.david-b@pacbell.net> <43A665F7.7020404@ru.mvista.com> <200512200011.57052.david-b@pacbell.net>
In-Reply-To: <200512200011.57052.david-b@pacbell.net>
Content-Type: text/plain; charset=KOI8-R; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1107
Lines: 27

David Brownell wrote:

>>The list setting commands are pretty essential and will not add a lot to 
>>the assembly code.
>>    
>>
>
>I'm not totally averse to such changes, but you don't seem to be making
>the best arguments.  Example:  they're clearly not "essential" because
>transfer queues work today with the lists at the spi_message level.
>  
>
One more reason for that that came out only recently: suppore we're 
adding transfers to an already configured message (i. e. with some 
transfers set up already). This 'chaning' may happen for some kinds of 
devices. And in case transfers is an array, we should either be apriory 
aware of whether the chaining will take place or allocate an array large 
enough to hold additional transfers. Neither of these look good to me, 
and having a linked list of transfers will definitely solve this problem.

Vitaly

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/