From: Adrian Hunter <adrian.hunter@nokia.com>
To: "Ghorai, Sukumar" <s-ghorai@ti.com>
Cc: Chris Ball <cjb@laptop.org>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>
Subject: Re: [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
>
WARNING: multiple messages have this Message-ID (diff)
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
>
next prev parent reply other threads:[~2010-09-28 18:33 UTC|newest]
Thread overview: 54+ 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 11:27 ` Sukumar Ghorai
2010-07-27 13:22 ` Adrian Hunter
2010-07-27 13:22 ` Adrian Hunter
2010-07-27 13:32 ` Ghorai, Sukumar
2010-07-27 13:32 ` Ghorai, Sukumar
2010-07-28 8:41 ` Adrian Hunter
2010-07-28 8:41 ` Adrian Hunter
2010-09-10 11:30 ` Ghorai, Sukumar
2010-09-10 11:30 ` Ghorai, Sukumar
2010-09-10 11:43 ` Adrian Hunter
2010-09-10 11:43 ` Adrian Hunter
2010-09-10 11:48 ` Ghorai, Sukumar
2010-09-10 11:48 ` Ghorai, Sukumar
2010-09-10 13:02 ` Adrian Hunter
2010-09-10 13:02 ` Adrian Hunter
2010-09-14 5:15 ` Ghorai, Sukumar
2010-09-14 5:15 ` Ghorai, Sukumar
2010-09-20 7:54 ` Adrian Hunter
2010-09-20 7:54 ` Adrian Hunter
2010-09-20 8:57 ` Ghorai, Sukumar
2010-09-20 8:57 ` Ghorai, Sukumar
2010-09-20 11:49 ` Adrian Hunter
2010-09-20 11:49 ` Adrian Hunter
2010-09-20 12:37 ` Ghorai, Sukumar
2010-09-20 12:37 ` Ghorai, Sukumar
2010-09-20 13:09 ` Adrian Hunter
2010-09-20 13:09 ` Adrian Hunter
2010-09-20 13:25 ` Ghorai, Sukumar
2010-09-20 13:25 ` Ghorai, Sukumar
2010-09-20 13:37 ` Russell King - ARM Linux
2010-09-20 13:37 ` Russell King - ARM Linux
2010-09-22 5:32 ` Ghorai, Sukumar
2010-09-22 5:32 ` Ghorai, Sukumar
2010-09-22 12:43 ` Chris Ball
2010-09-22 12:43 ` Chris Ball
2010-09-22 12:51 ` Ghorai, Sukumar
2010-09-22 12:51 ` Ghorai, Sukumar
2010-09-24 14:35 ` Ghorai, Sukumar
2010-09-24 14:35 ` Ghorai, Sukumar
2010-09-28 15:03 ` Ghorai, Sukumar
2010-09-28 15:03 ` Ghorai, Sukumar
2010-09-28 18:32 ` Adrian Hunter [this message]
2010-09-28 18:32 ` Adrian Hunter
2010-09-28 18:59 ` Ghorai, Sukumar
2010-09-28 18:59 ` Ghorai, Sukumar
2010-09-28 20:05 ` Adrian Hunter
2010-09-28 20:05 ` Adrian Hunter
2010-09-29 5:59 ` Ghorai, Sukumar
2010-09-29 5:59 ` Ghorai, Sukumar
2010-08-27 20:59 ` Chris Ball
2010-08-27 20:59 ` Chris Ball
2010-08-30 19:09 ` Ghorai, Sukumar
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=cjb@laptop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=s-ghorai@ti.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.