On Wed, May 9, 2012 at 8:20 PM, Philip Rakity <prakity@xxxxxxxxxxx> wrote:
>
> On Apr 13, 2012, at 7:39 AM, Namjae Jeon wrote:
>
>> Hi. Venkatraman.
>>
>> You fixed 10 times. why is it 10 times ?
>> and checking err from mmc_send_status is not needed ? is it also
>> infinite case ?
>>
>> Thanks.
>>
>> 2012/4/13 Venkatraman S <svenkatr@xxxxxx>:
>>> Try to send HPI only a fixed number of times till it is
>>> successful. One successful transfer is enough - but wait
>>> till the card comes out of transfer state.
>>> Return an error if the card was not in programming state to
>>> begin with - so that the caller knows that HPI was not sent.
>>>
>>> Reported-by: Alex Lemberg <Alex.Lemberg@xxxxxxxxxxx>
>>> Signed-off-by: Venkatraman S <svenkatr@xxxxxx>
>>> ---
>>> drivers/mmc/core/core.c | 34 ++++++++++++++++++----------------
>>> 1 file changed, 18 insertions(+), 16 deletions(-)
>>>
>>> diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
>>> index e541efb..ceabef5 100644
>>> --- a/drivers/mmc/core/core.c
>>> +++ b/drivers/mmc/core/core.c
>>> @@ -401,7 +401,7 @@ EXPORT_SYMBOL(mmc_wait_for_req);
>>> */
>>> int mmc_interrupt_hpi(struct mmc_card *card)
>>> {
>>> - int err;
>>> + int err, i;
>>> u32 status;
>>>
>>> BUG_ON(!card);
>>> @@ -421,27 +421,29 @@ int mmc_interrupt_hpi(struct mmc_card *card)
>>> /*
>>> * If the card status is in PRG-state, we can send the HPI command.
>>> */
>>> + err = -EINVAL;
>>> if (R1_CURRENT_STATE(status) == R1_STATE_PRG) {
>>> - do {
>>> - /*
>>> - * We don't know when the HPI command will finish
>>> - * processing, so we need to resend HPI until out
>>> - * of prg-state, and keep checking the card status
>>> - * with SEND_STATUS. If a timeout error occurs when
>>> - * sending the HPI command, we are already out of
>>> - * prg-state.
>>> - */
>>> + /* To prevent an infinite lockout, try to send HPI
>>> + * a fixed number of times and bailout if it can't
>>> + * succeed.
>>> + */
>>> + for (i = 0; i < 10 && err != 0 ; i++)
>
>
> would it make more sense to check time as well as retry count ?
> worry that count may be too short or behavior is dependent on card manufacturer.
>
This patch is discarded. Let me know if you have some comments on the
follow up patch with
the subject "mmc: fix HPI execution sequence"
>
>>> err = mmc_send_hpi_cmd(card, &status);
>>> - if (err)
>>> + /* Once HPI was sent successfully, the card is
>>> + * supposed to be back to transfer state.
>>> + */
>>> + do {
>>> + if (err) {
>>> pr_debug("%s: abort HPI (%d error)\n",
>>> mmc_hostname(card->host), err);
>>> -
>>> - err = mmc_send_status(card, &status);
>>> - if (err)
>>> break;
>>> + }
>>> + err = mmc_send_status(card, &status);
>>> } while (R1_CURRENT_STATE(status) == R1_STATE_PRG);
>>> - } else
>>> - pr_debug("%s: Left prg-state\n", mmc_hostname(card->host));
>>> + } else {
>>> + pr_debug("%s: Can't send HPI. State=%d\n",
>>> + mmc_hostname(card->host), R1_CURRENT_STATE(status));
>>> + }
>>>
>>> out:
>>> mmc_release_host(card->host);
>>> --
>>> 1.7.10.rc2
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
