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 --]
next prev parent 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®