mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Pierre Ossman <pierre@ossman.eu>
To: Harald Welte <HaraldWelte@viatech.com>
Cc: Linux Kernel Mailinglist <linux-kernel@vger.kernel.org>,
	JosephChan@via.com.tw, Bruce Chang <BruceChang@via.com.tw>
Subject: Re: [PATCH] mmc: Add new via-sdmmc host controller driver
Date: Sun, 14 Jun 2009 12:55:37 +0200	[thread overview]
Message-ID: <20090614125537.065d706a@mjolnir.ossman.eu> (raw)
In-Reply-To: <20090614065256.GJ2854@prithivi.gnumonks.org>

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

On Sun, 14 Jun 2009 14:52:56 +0800
Harald Welte <HaraldWelte@viatech.com> wrote:

> > 
> > You need to do the removal as the first step 
> 
> Thanks, I've fixed this in my tree. 
> 
> Looking at other drivers, imxmmc seems to get this wrong, too.
> 

Quite right. I suppose someone should have a look at that...

> > and you might need to explicitly kill any ongoing requests.
> 
> you mean something like the snippet in sdhci.c:
> ======
>        if (dead) {
>                 spin_lock_irqsave(&host->lock, flags);
> 
>                 host->flags |= SDHCI_DEVICE_DEAD;
> 
>                 if (host->mrq) {
>                         printk(KERN_ERR "%s: Controller removed during "
>                                 " transfer!\n", mmc_hostname(host->mmc));
> 
>                         host->mrq->cmd->error = -ENOMEDIUM;
>                         tasklet_schedule(&host->finish_tasklet);
>                 }
> 
>                 spin_unlock_irqrestore(&host->lock, flags);
>         }
> ======
> 
> Why is sdhci about the only driver that does it?  What decides if we need
> to kill ongoing requests or not?
> 

I guess I haven't kept an eye on it so the others are simply buggy.

> Also, you stated that mmc_remove_host needs to be the first step.  However,
> sdhci first kills the ongoing rquest (if "dead"), and then removes the host.
> 

Right, because the reason you need to end the request is that failure
to do so will wedge the MMC system and mmc_remove_host() will never
return.

Normally the requests will eventually be completed by interrupts coming
from the hardware, but if it got removed then that might not happen.

Rgds
-- 
     -- Pierre Ossman

  WARNING: This correspondence is being monitored by the
  Swedish government. Make sure your server uses encryption
  for SMTP traffic and consider using PGP for end-to-end
  encryption.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2009-06-14 10:55 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12  7:59 Harald Welte
2009-06-13 11:43 ` Pierre Ossman
2009-06-14  6:52   ` Harald Welte
2009-06-14 10:55     ` Pierre Ossman [this message]
2009-06-14 13:51       ` Harald Welte
2009-06-17 18:22 Harald Welte
2009-06-18  5:17 ` Joe Perches
2009-06-19 19:30 ` Pierre Ossman

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=20090614125537.065d706a@mjolnir.ossman.eu \
    --to=pierre@ossman.eu \
    --cc=BruceChang@via.com.tw \
    --cc=HaraldWelte@viatech.com \
    --cc=JosephChan@via.com.tw \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®