Hi,
On Fri, Apr 13 2012, Venkatraman S wrote:
> 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 <[email protected]>
> Signed-off-by: Venkatraman S <[email protected]>
> ---
> 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++)
> err = mmc_send_hpi_cmd(card, &status);
> - if (err)
> + /* Once HPI was sent successfully, the card is
> + * supposed to be back to transfer state.
> + */
Minor nit: for consistency, please always use:
/*
* Kernel-style comment blocks.
*/
.. even though they waste the first line. :)
Thanks,
- Chris.
--
Chris Ball <[email protected]> <http://printf.net/>
One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
