linux-kernel - RE: [PATCH] mmc: dw_mmc: exynos: Turn SDIO interrupts on

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Apr 2013 18:30:51 +0900
From:	Seungwon Jeon <tgih.jun@...sung.com>
To:	'Doug Anderson' <dianders@...omium.org>
Cc:	'Chris Ball' <cjb@...top.org>,
	'Thomas Abraham' <thomas.abraham@...aro.org>,
	'Bing Zhao' <bzhao@...vell.com>,
	'Jaehoon Chung' <jh80.chung@...sung.com>,
	'Sachin Kamat' <sachin.kamat@...aro.org>,
	'Olof Johansson' <olof@...om.net>, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: RE: [PATCH] mmc: dw_mmc: exynos: Turn SDIO interrupts on

On Tuesday, April 16, 2013, Doug Anderson
> Seungwon,
> 
> On Mon, Apr 15, 2013 at 5:14 AM, Seungwon Jeon <tgih.jun@...sung.com> wrote:
> >> +             MMC_CAP_8_BIT_DATA | MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> >> +     MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> > This line for [1]
> >> +     MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> >> +     MMC_CAP_CMD23 | MMC_CAP_SDIO_IRQ,
> > [1] is for mshc1. mshc1 is only used for SDIO.
> > As I know, The others are improper for SDIO.
> 
> I'm nearly certain that all of the ports are OK for SDIO.  Specifically:
> 
> * On the ARM Chromebook (exynos5250) we are using mmc3 (12230000) for
> the SDIO connection to WiFi.
> 
> * I have plugged in an external WiFi module to the SD card slot on the
> ARM Chromebook and seen it work (including interrupts).  This is mmc2
> (12220000).
Yes, we also have tested WiFi module type of sd slot with ch#2.

> 
> * I have seen a board where mmc1 was wired up to WiFi and seen it work.
Yes, mmc2, mmc3 can 
> 
> 
> It is possible that mmc0 wouldn't work for SDIO.  I've never tested it
> since mmc0 is intended for eMMC and every system I've worked with has
> eMMC on that port.  There is some evidence that mmc0 would work for
> SDIO, though: there is a muxing slot on GPC0[2] for SD_0_CARD_INT_n.
> That implies that mmc0 ought to also work for SDIO (and even could be
> configured for an external eSDIO interrupt, I guess).
I don't mean that SDIO is impossible except in ch#1.
Basically, SDIO device can be attached on all host's channel and may works.
In case of ch#0, it's almost dedicated for eMMC and is actually arranged for eMMC.
And ch#1 is recommended for SDIO and can support UHS-I speed.
So, I don't think MMC_CAP_SDIO_IRQ is needed to ch#0.
Similarly, MMC_CAP_SDIO_IRQ is not a good choice for ch#2, ch#3 by default.
If needed for specific channel, it can be got from dts as property.
if (of_find_property(np, "cap-sdio-irq", NULL))
	pdata->caps |= MMC_CAP_SDIO_IRQ;
	
Thanks,
Seungwon Jeon
> 
> 
> Thanks!
> 
> -Doug

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/