linux-kernel - Re: [PATCH] mmc: core: Remove timeout when enabling cache

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:   Tue, 20 Nov 2018 15:39:16 +0530
From:   Faiz Abbas <faiz_abbas@...com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Wolfram Sang <wsa@...-dreams.de>,
        Sjoerd Simons <sjoerd.simons@...labora.co.uk>
CC:     "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        <kernel@...labora.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Hongjie Fang <hongjiefang@...micro.com>,
        Bastian Stender <bst@...gutronix.de>,
        Kyle Roeschley <kyle.roeschley@...com>,
        Wolfram Sang <wsa+renesas@...g-engineering.com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Harish Jenny K N <harish_kandiga@...tor.com>,
        Simon Horman <horms+renesas@...ge.net.au>
Subject: Re: [PATCH] mmc: core: Remove timeout when enabling cache

Hi Uffe,

On 20/11/18 2:54 PM, Ulf Hansson wrote:
> On 7 November 2018 at 09:47, Wolfram Sang <wsa@...-dreams.de> wrote:
>>
>>> That also happens to be one of the cards we deploy; However i did
>>> wonder about adding a quirk but decided against it as it was not clear
>>> to me from the specification that CACHE ON really is meant to complete
>>> within GENERIC_CMD6_TIMEOUT. That and i fret about ending up in hit-a-
>>> mole games as the failure is really quite tedious (boot failure).
>>
>> I agree that we should use the more defensive variant as a default. I
>> mean there should be no performance regression since most cards will
>> respond just faster, or? The only downside I could see is that we might
>> miss a real timeout with no bounds set and might get stuck?
> 
> Well, you have a point, but still it's kind of nice to know which
> cards are behaving well and which ones that doesn't. Hence I think I
> prefer to stick using a quirk, unless you have a strong opinion.
> 
> Note that, in this case we can use CMD13 to poll for busy, which then
> means it also works for those hosts that doesn't support HW busy
> detection, without getting additional delays. If this hasn't been the
> case, we must be using a quirk, but now we are more free to choose.
> 
>> Maybe it is
>> worth contacting eMMC spec people to at least know what is the expected
>> behaviour?
> 
> According to the spec, the GENERIC_CMD6_TIMEOUT should be sufficient.
> So this card is not conforming to the spec, I think it's as simple as
> that.
> 

Is the QUIRK patch acceptable as it is or do you require some sort of
errata from the card manufacturers?

Thanks,
Faiz