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:	Wed, 15 Sep 2010 17:10:45 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Hein_Tibosch <hein_tibosch@...oo.es>
Cc:	Ben Nizette <bn@...sdigital.com>, linux-mmc@...r.kernel.org,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Chris Ball <cjb@...top.org>
Subject: Re: [PATCH] mmc: Reduce fOD to 200 kHz if possible

Hein_Tibosch <hein_tibosch@...oo.es> wrote:
> >> We've now submitted one fix each, mine was similar to yours [1] but there's been movement on Hein's more comprehensive patch recently [2].  I don't know who's supposed to be merging MMC patches atm, Chris Ball added on CC on a hunch.
> > Thanks for the references. IMO Hein's patch is overkill. There is
> > absolutely no reason why 200 kHz should be a problem on any setup, and
> > I haven't found any indication in any discussions that it is.
> >
> 
> I have also seen situations in which the SD will only start up at 180 Khz
> or lower.

Ok, so my patch would obviously not fix those. Could you tell me more
about those situations? What kind of board are you running at, etc?

> IMO my patch is indeed a bit of an overkill (the amount of code changed),
> I'd rather see a patch like yours or Ben's, but settings fOD at 100 or 50 Khz.

I guess 100 kHz would make sense. 50 kHz is not allowed according to
the SD card spec.

Another solution might be to introduce a new field, f_max_od, which the
host controller driver could use to limit the bus frequency in open
drain mode.

> It was Pierre who suggested to try several frequencies[1]: most systems will start
> using 400 Khz (so they won't suffer any loss of performance) and in some rare
> cases, the SD will only be identified at 100 Khz (which does happen, sometimes)

I think any performance hit in open drain mode is not likely to be
noticeable, as it is only used for a couple of commands. The only thing
that really matters for performance is push-pull mode, where too strong
pull-ups might cause problems at high speed.

But if there really are cards that have problems at 100 kHz, I guess
your patch might be the best bet.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ