linux-kernel - Re: [PATCH] mmc: make sdhci work with ricoh mmc controller

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:	Thu, 3 Jun 2010 21:42:23 -0700
From:	Philip Langdale <philipl@...rt.org>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>, adq_dvb@...skialf.net,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: [PATCH] mmc: make sdhci work with ricoh mmc controller

On Thu, 03 Jun 2010 20:35:31 +0300
Maxim Levitsky <maximlevitsky@...il.com> wrote:

> On Thu, 2010-06-03 at 10:05 -0700, Philip Langdale wrote: 
> > On Thu, 3 Jun 2010 09:39:14 -0700
> > Philip Langdale <philipl@...rt.org> wrote:
> > 
> > > > > 
> > > > > Have you been able to establish if 4bit and high-speed
> > > > > operations work correctly through the MMC controller? I note
> > > > > that you didn't set SDHCI_CAN_DO_HISPD.
> > > > Didn't test that yet, will do.
> > > > I hope my MMCPlus card can do high-speed.
> > > 
> > > I should get a chance today to test this as well; I'll let you
> > > know what I see.
> > > 
> > 
> > Ok, I was able to try it out and setting HISPD works and 4bit seems
> > to work too. My MMCplus cards run at the same speed with either
> > controller.
> I too confirm that.

On this subject:

1) Would it make sense to have the hard-coded caps reflect the full
set of caps you see on the sdhci side?

2) We ought to be able to set the MMC high-speed flag for this
controller; I've tried it out and it works fine. The default sdhci
code will never set this flag. I think it would need to an additional
quirk. Pierre argued against setting it on the basis that SD high speed
has slightly different timings; I haven't seen hardware where this
has been an issue.

> However that suspend/resume race is tough one.
> The problem seems that controller doesn't like both devices to be
> poked at same time, and normally they won't, but here on resume both
> are tested for a card, and this is done asynchronously by mmc core.
> 
> I will get to bottom of this sooner or later (I hope).

Hmm. So, if the issue is the test, then you should be able to serialize
in mmc core instead of forcing sync resume in general. An ugly way would
be a quirk that says to serialize all card tests if the controller is
present in the system. In practice it would be fine as systems won't
have arbitrary other sdhci controllers if they have this ricoh mmc
thing. But yes, it isn't clean. :-P

--phil
--
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/