linux-kernel - Re: SDHCI AM654 driver delaying boot time

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] [day] [month] [year] [list]

Message-ID: <df204135-f12b-4892-963c-a4c87b1dd3cb@intel.com>
Date:   Tue, 14 Nov 2023 10:25:03 +0200
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Francesco Dolcini <francesco@...cini.it>,
        Nishanth Menon <nm@...com>
Cc:     João Paulo Silva Gonçalves 
        <joao.goncalves@...adex.com>,
        "faiz_abbas@...com" <faiz_abbas@...com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Francesco Dolcini <francesco.dolcini@...adex.com>
Subject: Re: SDHCI AM654 driver delaying boot time

On 10/11/23 16:19, Francesco Dolcini wrote:
> Hello Nishant,
> 
> On Thu, Nov 09, 2023 at 11:51:59AM -0600, Nishanth Menon wrote:
>> On 18:56-20231108, João Paulo Silva Gonçalves wrote:
>>> Hello all, 
>>>
>>> We are trying to minimize boot time for our AM62 devices.
>>> Unfortunately, we have identified a delay of approximately 1.5
>>> seconds caused by the sdhci_am654 driver. This delay is a result of
>>> a timeout within the driver (MAX_POWER_ON_TIMEOUT) and was
>>> introduced in commit 7ca0f16 ("mmc: sdhci_am654: Add workaround for
>>> card detect debounce timer"). This issue arises only when there is
>>> no SD card present in the MMC slot.  We tested the driver with a
>>> lower timeout value and everything worked. However, as indicated in
>>> the commit message, this timeout may be related to the way the sdhci
>>> controller hardware IP works. Currently, the driver employs a sort
>>> of a "busy loop" to wait for this timeout to pass delaying the boot.
>>> Why is need to busy loop for this timeout? Is it possible to wait
>>> for it in the backgroud? Am I am missing something here? 
>>
>> I am not an mmc expert, but, Isn't this sequence part of the programmer
>> manual in the TRM[1]?
> 
> Probably original question from Joao was not fully understood.
> 
> It is clear why the code is waiting for the CD, the issue we are
> experiencing is that the whole boot is delayed by 1.5 seconds because of
> that piece of code for no reason.
> 
> - SD card exists in the system, but it's not used and the card slot is empty
> - We boot from eMMC (that has no CD pin)
> - Boot is delayed by 1.5 second because of that piece of code

So maybe don't use that code for eMMC?