All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Subject: Re: [RFT] mmc: tmio: reset device on timeout, too
Date: Wed, 9 Sep 2020 13:37:45 +0200	[thread overview]
Message-ID: <20200909113745.GK2272@ninjato> (raw)
In-Reply-To: <CAPDyKFr24YxoJ3m5r1C_4-UAdtJQp_MK0+wwZjsQXzrs5dxLjw@mail.gmail.com>

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

Hi Ulf,

> > Hmm, there are some wireless drivers using it as well. I am confused, is
> > this considered "upper layer"?
> >
> > drivers/net/wireless/ath/ath10k/sdio.c: ret = mmc_hw_reset(ar_sdio->func->card->host);
> > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c:        mmc_hw_reset(sdiodev->func1->card->host);
> > drivers/net/wireless/marvell/mwifiex/sdio.c:    ret = mmc_hw_reset(func->card->host);
> > drivers/net/wireless/ti/wlcore/sdio.c:  mmc_hw_reset(card->host);
> 
> Correct, these are "upper layers". The same applies for the mmc block
> device driver.
> 
> In this way there is a guarantee that the struct mmc_card is still present.

Ah, now I get it. "upper layers" as in consumers. And because consumers
sit on a card, this guarantees that mmc_card is still there. Correct?

> That would be great. I appreciate all kinds of improvements on the doc parts.

You are welcome!

> Perhaps a better option is to return a specific error code for the
> last request, that makes the core run mmc_hw_reset(). Or potentially,
> add a host cap and let the core treat some error code, specifically
> for hosts like tmio.

A specific errno could work. I don't see the advantage of a CAP (besides
it is rather a quirk than a cap). We could also have
'mmc_controller_card_reset()' or something which ensures mmc_card is
present and let that controllers call when they see fit. Or?

Thanks for your help,

   Wolfram


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

  reply	other threads:[~2020-09-09 11:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  8:16 [RFT] mmc: tmio: reset device on timeout, too Wolfram Sang
2020-08-28 12:18 ` Yoshihiro Shimoda
2020-08-28 12:35 ` Ulf Hansson
2020-08-30 13:03   ` Wolfram Sang
2020-09-09 11:24     ` Ulf Hansson
2020-09-09 11:37       ` Wolfram Sang [this message]
2020-09-09 12:45         ` Ulf Hansson
2020-09-15 10:05           ` Wolfram Sang

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=20200909113745.GK2272@ninjato \
    --to=wsa+renesas@sang-engineering.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=yoshihiro.shimoda.uh@renesas.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.