linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: adrian.hunter@nokia.com (Adrian Hunter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] mmc: failure of block read wait for long time
Date: Tue, 28 Sep 2010 21:32:36 +0300	[thread overview]
Message-ID: <4CA234C4.8070907@nokia.com> (raw)
In-Reply-To: <2A3DCF3DA181AD40BDE86A3150B27B6B03560991F7@dbde02.ent.ti.com>

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@laptop.org>    <http://printf.net/>
>>>> One Laptop Per Child
>

  reply	other threads:[~2010-09-28 18:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-27 11:27 [PATCH] mmc: failure of block read wait for long time Sukumar Ghorai
2010-07-27 13:22 ` Adrian Hunter
2010-07-27 13:32   ` Ghorai, Sukumar
2010-07-28  8:41     ` Adrian Hunter
2010-09-10 11:30       ` Ghorai, Sukumar
2010-09-10 11:43         ` Adrian Hunter
2010-09-10 11:48           ` Ghorai, Sukumar
2010-09-10 13:02             ` Adrian Hunter
2010-09-14  5:15               ` Ghorai, Sukumar
2010-09-20  7:54                 ` Adrian Hunter
2010-09-20  8:57                   ` Ghorai, Sukumar
2010-09-20 11:49                     ` Adrian Hunter
2010-09-20 12:37                       ` Ghorai, Sukumar
2010-09-20 13:09                         ` Adrian Hunter
2010-09-20 13:25                           ` Ghorai, Sukumar
2010-09-20 13:37                           ` Russell King - ARM Linux
2010-09-22  5:32                             ` Ghorai, Sukumar
2010-09-22 12:43                               ` Chris Ball
2010-09-22 12:51                                 ` Ghorai, Sukumar
2010-09-24 14:35                                 ` Ghorai, Sukumar
2010-09-28 15:03                                 ` Ghorai, Sukumar
2010-09-28 18:32                                   ` Adrian Hunter [this message]
2010-09-28 18:59                                     ` Ghorai, Sukumar
2010-09-28 20:05                                       ` Adrian Hunter
2010-09-29  5:59                                         ` Ghorai, Sukumar
2010-08-27 20:59 ` Chris Ball
2010-08-30 19:09   ` Ghorai, Sukumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CA234C4.8070907@nokia.com \
    --to=adrian.hunter@nokia.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).