From: Chris Ball <cjb@laptop.org>
To: Philip Rakity <prakity@marvell.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>
Subject: Re: sdhci: Best Practice Question
Date: Sun, 26 Sep 2010 17:40:05 +0100 [thread overview]
Message-ID: <20100926164005.GC19772@void.printf.net> (raw)
In-Reply-To: <E6553F30-7D88-476A-A8AF-3F7793FA4DE0@marvell.com>
Hi Philip,
On Sat, Sep 25, 2010 at 01:08:20PM -0700, Philip Rakity wrote:
> The change proposed by Richard Zhu for handling write protect uses
> only a callback.
>
> <snip>
> static int sdhci_get_ro(struct mmc_host *mmc)
> {
> struct sdhci_host *host;
> unsigned long flags;
> int present;
>
> host = mmc_priv(mmc);
>
> if (host->ops->get_ro)
> return host->ops->get_ro(host);
>
> spin_lock_irqsave(&host->lock, flags);
>
> <end snip>
>
> What is the correct practice?
I think that the get_ro hook is reasonable in this case -- we're saying
that the host has a sufficiently weird WP setup that sdhci doesn't know
what we're supposed to do (unlike SDHCI_QUIRK_INVERTED_WRITE_PROTECT).
I'd be curious to hear what others think, though. Should we be simply
moving away from adding new quirks, or just limiting them to cases where
a full hook isn't warranted?
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
prev parent reply other threads:[~2010-09-26 16:40 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-25 20:08 sdhci: Best Practice Question Philip Rakity
2010-09-26 0:43 ` [PATCH] sdhci: sepearate get_ro into code that calls platform and helper Philip Rakity
2010-09-26 0:44 ` [PATCH] sdhci: seperate out reset so if platform specific helper exists it is called Philip Rakity
2010-09-26 16:45 ` [RFC] sdhci: SDHCI_QUIRK_BROKEN_CARD_DETECTION Philip Rakity
2010-09-26 16:40 ` Chris Ball [this message]
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=20100926164005.GC19772@void.printf.net \
--to=cjb@laptop.org \
--cc=linux-mmc@vger.kernel.org \
--cc=prakity@marvell.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.