[PATCH] mmc: failure of block read wait for long time

[Adrian Hunter]

On 28/09/10 18:03, Ghorai, Sukumar wrote:
> Chris and Adrian,
>
> [..snip..]
>>
>> Chris and Adrian,
>>
>> [..snip..]
>>>
>>>> -----Original Message-----
> [..snip..]
>>>> Subject: Re: [PATCH] mmc: failure of block read wait for long time
>>>>
>>>> On Wed, Sep 22, 2010 at 11:02:08AM +0530, Ghorai, Sukumar wrote:
>>>>> Would you please review and merge this patch [1] (attached too)?
>>>>> [1] http://comments.gmane.org/gmane.linux.kernel.mmc/2714
>>>>
>>>> I've been following the thread.  I believe Adrian has NACKed this
>> patch,
>>>> by saying "It is absolutely unacceptable to return I/O errors to the
>>>> upper layers for segments that do not have errors."
>>>
>>> [Ghorai]
>>> I think Russell also mentioned his opinion. Would you please add your
>> idea
>>> too?
>>>
>>> 1. I would prefer Adrian to explain again what this statement means, in
>>> the context - data read fail and how we make it success?

Because I/O requests are made up of segments and every segment can be a
success or failure.

>>>
>>> 2. if data read fail for sector(x) why we have to try for
>>> sector(x+1, ..x+n)?

See answer to q. 1

>>>
>>> 3. how to inform reader function which sector having the valid data out
>> of
>>> (1...n) sectors.

__blk_end_request() does that

>>>
>>> 4. do we have any driver/code in Linux or any other os, which give
>> inter-
>>> leave data and return as success?

Here is the problem with that question.  The *same* I/O request
can have data for *different*sources.

>>>
>> [Ghorai] please reply with your input on my/ Russell's suggestion?
> [Ghorai] any input?

I have a question for you.  What use cases do you want to address
  - other than card removal?

>>
>>>>
>>>> I think it's possible to merge patches to improve the situation (such
>>>> as the idea of noticing a card disappearing earlier), but your initial
>>>> patch is not the patch to do that.  You should continue to work with
>>>> Adrian -- when he's happy that a patch does not break the semantics
>>>> above, we can consider merging it.
>>>>
>>>> Thanks,
>>>>
>>>> --
>>>> Chris Ball<cjb at laptop.org>    <http://printf.net/>
>>>> One Laptop Per Child
>