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]
Message-ID: <20100915125138.1f25e4b1@hskinnemoen-d830>
Date:	Wed, 15 Sep 2010 12:51:38 +0200
From:	Haavard Skinnemoen <haavard.skinnemoen@...el.com>
To:	Ben Nizette <bn@...sdigital.com>
Cc:	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

Ben Nizette <bn@...sdigital.com> wrote:
> On 15/09/2010, at 6:59 PM, Haavard Skinnemoen wrote:
> 
> > Since the identification frequency was increased to 400 kHz, my
> > ATSTK1000 board has not been able to initialize any MMC or SD cards.
> > Reducing the identification mode frequency to 200 kHz fixes the problem.
> > 
> > This is definitely a board-specific issue, probably due to weak pull-up
> > resistor values, but this is the simplest fix I could come up with.  
> 
> I wonder whether there's an Atmel reference schematic around with an incorrect resistor value on it, the only three people I know affected by this are myself, Hein Tibosch and you, all on AVR32.

Yes, if you've used the STK1000 schematics as a reference, the resistor
values are probably a bit on the high side. I can't really suggest any
better values, as I don't remember what they should be, and the various
specs are quite inconsistent so it's not straightforward to find the
best values.

On the other hand, you could argue that the resistor values are fine as
they are, and that the Linux MMC subsystem is broken because it runs
the bus faster than what the hardware allows. Replacing the resistors
with stronger ones might reduce the maximum speed in push-pull mode, so
I wouldn't necessarily recommend it, especially when it's trivial to fix
the issue in software.

> 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.

The reason why fOD was set to 400 kHz in the first place is that some
controllers have a very low f_min so running the initialization at that
frequency causes problems. Which makes sense because the SD standard
clearly says that the clock can't be slower than 100 kHz.

But I have never seen any reasons why we absolutely _have_ to run the
clock at the maximum frequency allowed by the spec. In fact, Sascha
Hauer, who was the one who changed the minimum clock frequency to 400
kHz, said he would be fine with any frequency between 50 kHz and 400
kHz [1].

Haavard

[1] http://lkml.org/lkml/2010/1/5/120
--
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