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  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, 20 Mar 2014 13:26:53 +0100
From:	Michal Simek <>
To:	Sören Brinkmann <>
CC:	Mike Looijmans <>,
	Eli Billauer <>,,,,,
Subject: Re: [PATCH v2] mmc: sdhci: add quirk for broken write protect detection


On 03/06/2014 05:42 PM, Sören Brinkmann wrote:
> On Thu, 2014-03-06 at 02:31PM +0100, Mike Looijmans wrote:
>> On 03/04/2014 10:00 PM, Sören Brinkmann wrote:
>>> On Tue, 2014-03-04 at 10:06PM +0200, Eli Billauer wrote:
>>>> Hello Sören,
>>>> wp-inverted solves the practical problem indeed, and fools the
>>>> driver into thinking that the card has an inverted write protection
>>>> sensor, and the logic zero that it finds in the hardware register
>>>> means that the card isn't write protected.
>>>> I'm insisting on this patch, because I think that the device tree
>>>> should describe the hardware as it is, and not fool the driver into
>>>> behaving the way we want it to. These tricks always bite back later
>>>> on.
>>> Well, why is broken-wp more accurate than wp-inverted? Strictly
>>> speaking the WP is there and working, it's just tied off to some value
>>> you want to have interpreted the other way.
>>> Anyway, seems like this is solvable with wp-inverted and whether the
>>> additional quirk is needed I leave to others do decide.
>> I've begged for this patch - or a similar one - to be included too,
>> because on our boards, the "wp" value appears to be sort of random.
>> Out of 5 prototype boards, 3 would only boot with wp-inverted while
>> the other 2 wouldn't boot with wp-inverted set.
>> In our case I really don't know (and I don't care either) to which
>> logic level the wp happens to think it's wired. I just want to be
>> able to tell the driver that the WP line is
>> free-floating-and-might-have-any-random-value-at-any-given-moment
>> which is a bit long, so I'd go for disable-wp instead.
> Could you provide the design you use and give more details? According to
> the people I talked to, the signal should never float, unless you pin it
> out and don't drive it.
> Actually, you should open a support case for this. It is not supposed to
> happen.

we have got this from Mike (we couldn't reply because he has lost this email

"I think I found the issue. In ps7_init.c as generated by the tools, it sets the "WP" pin not to EMIO, but to MIO 0. We use pin 0 for a status LED.

# devmem 0XF8000830

Register 0XF8000830 is SD0_WP_CD_SEL, and 0x002E0000 sets CD to pin 46 and WP to pin "0", not to EMIO as I specified in the design.

Eli: Maybe you have the same issue as Mike. Can you please check it?


Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu -
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform

Download attachment "signature.asc" of type "application/pgp-signature" (264 bytes)

Powered by blists - more mailing lists