linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@zonque.org>
To: Bing Zhao <bzhao@marvell.com>, Tony Lindgren <tony@atomide.com>,
	Andreas Fenkart <afenkart@gmail.com>
Cc: James Cameron <quozl@laptop.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>
Subject: Re: mwifiex card reset
Date: Tue, 01 Jul 2014 09:52:40 +0200	[thread overview]
Message-ID: <53B268C8.4030703@zonque.org> (raw)
In-Reply-To: <477F20668A386D41ADCC57781B1F70430FE5F37540@SC-VEXCH1.marvell.com>

Hi Bing,

On 07/01/2014 08:44 AM, Bing Zhao wrote:
>> Hence, we'll need some sort of internal API for this, and a phandle
>> in dts. I wonder whether that glue logic might be better off living
>> in the mmc core, as mwifiex might well be interfaced to other
>> hosts?
> 
> I may have missed something, but doesn't the MMC_POWER_OFF and
> MMC_POWER_ON|UP handling in controller driver help? Anyway the
> clocks/GPIOs/regulators are sort of platform dependent. Would it be
> better putting it in /arch/arm/mach-xxxxx/?

Regulators are not platform specific, they never were. For GPIOs and
clocks, we can simply depend on CONFIG_GPIO_GENERIC and
CONFIG_COMMON_CLK. I wouldn't even bother to care for anything else.
This way, we also get a way of referencing the resources in dts through
phandles for free.

What I was talking about above was that conducting the actual reset from
the helper must be something that either the mmc core or individual host
implementations can trigger. We need to repeat this action every time
mwifiex decides to call its reset routine, which is currently
implemented like this:

	mmc_remove_host(target);
	mdelay(20);
	mmc_add_host(target);

But I haven't looked into possible ways of implementation yet.
MMC_POWER_* might well be a suitable thing to hook into.


Thanks,
Daniel

  parent reply	other threads:[~2014-07-01  7:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-27 14:39 mwifiex card reset Andreas Fenkart
2014-06-28  5:22 ` James Cameron
2014-06-28  7:23   ` Tony Lindgren
2014-06-29  9:41     ` Andreas Fenkart
2014-06-30  6:19       ` Tony Lindgren
2014-06-30 19:30         ` Daniel Mack
2014-07-01  6:44           ` Bing Zhao
2014-07-01  6:57             ` James Cameron
2014-07-01  7:02               ` Bing Zhao
2014-07-01  7:03                 ` James Cameron
2014-07-01  7:41                   ` Tony Lindgren
2014-07-01 12:20               ` Yuvaraj Cd
2014-07-01 15:09                 ` Doug Anderson
2014-07-15 13:25                   ` Andreas Fenkart
2014-07-01  7:52             ` Daniel Mack [this message]
2014-07-01  8:44             ` Andreas Fenkart

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=53B268C8.4030703@zonque.org \
    --to=daniel@zonque.org \
    --cc=afenkart@gmail.com \
    --cc=bzhao@marvell.com \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=quozl@laptop.org \
    --cc=tony@atomide.com \
    --cc=ulf.hansson@linaro.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;
as well as URLs for NNTP newsgroup(s).