linux-kernel - Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit

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: <e703a068-810f-77fe-d702-138911669147@metafoo.de>
Date:   Thu, 25 Aug 2016 17:50:16 +0200
From:   Lars-Peter Clausen <lars@...afoo.de>
To:     Sören Brinkmann <soren.brinkmann@...inx.com>
Cc:     Zach Brown <zach.brown@...com>, mark.rutland@....com,
        devicetree@...r.kernel.org, ulf.hansson@...aro.org,
        linux-mmc@...r.kernel.org, adrian.hunter@...el.com,
        linux-kernel@...r.kernel.org, robh+dt@...nel.org,
        michal.simek@...inx.com, linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter
 to fake CD bit

On 08/25/2016 05:29 PM, Sören Brinkmann wrote:
> On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote:
>> On 08/25/2016 05:10 PM, Sören Brinkmann wrote:
>>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote:
>>>> The sdhci controller on xilinx zynq devices will not function unless
>>>> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html
>>>> In cases where it is impossible to provide the cd bit in hardware,
>>>> setting the controller to test mode and then setting inserted to true
>>>> will get the controller to function with out the cd bit.
>>>>
>>>> The device property "fake-cd" will let the arasan driver know it needs
>>>> to fake the cd bit for the controller inorder for the controller to
>>>> function with a SD card that does not provide the CD bit.
>>>
>>> I thought the CD is, if not pinned out, tied off to some valid logic
>>> level. Isn't it enough to specify cd-inverted if needed to make it work
>>> in those cases?
>>
>> It is always brought out to some pin, that is the problem on the Zynq. This
>> means you'd have to set at least one pin aside as dummy CD or WP pin. Which
>> is not always possible when you are tight on available pins.
> 
> I have to admit that I haven't looked at Vivado for quite a while. Is it
> possible to select EMIO for those pins? If those are not routed anything
> they should be tied to some logic level, I believe.
> If they are always forced to be on a physical pin, do you let that pin
> just float? Otherwise, the logic level should also be defined, give and
> take a logic inversion.

Yes, it is possible to source them from EMIO. We had the same issue with WP
on one of our boards and the routing to EMIO approach was one of the
solutions I considered. But I could not find documentation on whether and
how the pins are tied when the FPGA is not configured or what happens during
reconfiguration, is there a chance of glitches.

So I went with the software solution of specifying disable-wp for the slot
instead.

But even if using EMIO works I think correctly describing the hardware,
which is that there is no external WP or CD pin connected, is the better
approach rather than playing around with invert flags, which has a different
semantical meaning. Software can than work with that information and take
the approach it is best to handle the situation. And this approach might
change if we find better ways to handle it, whereas the hardware description
stays static.