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: <5072935e-d855-7029-1ac0-0883978f66e5@intel.com>
Date:   Fri, 24 Sep 2021 16:26:37 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Bean Huo <huobean@...il.com>, Ulf Hansson <ulf.hansson@...aro.org>
Cc:     Bean Huo <beanhuo@...ron.com>, linux-mmc@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/2] mmc: sdhci: Use the SW timer when the HW timer
 cannot meet the timeout value required by the device

On 24/09/21 4:08 pm, Bean Huo wrote:
> On Fri, 2021-09-24 at 15:17 +0300, Adrian Hunter wrote:
>>>>>          sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
>>>>> }
>>>>> The driver has detected that the hardware timer cannot meet the
>>>>> timeout
>>>>> requirements of the device, but we still use the hardware
>>>>> timer,
>>>>> which will
>>>>> allow potential timeout issuea . Rather than allowing a
>>>>> potential
>>>>> problem to exist, why can’t software timing be used to avoid
>>>>> this
>>>>> problem?
>>>> Timeouts aren't that accurate.  The maximum is assumed still to
>>>> work.
>>>> mmc->max_busy_timeout is used to tell the core what the maximum
>>>> is.
>>> mmc->max_busy_timeout is still a representation of Host HW timer
>>> maximum timeout count, isn't it? 
>>
>>
>> Not necessarily.  For SDHCI_QUIRK2_DISABLE_HW_TIMEOUT it would be
>>
>> set to zero to indicate no maximum.
> 
> yes, this is the purpose of the patch, for the host controller without
> quirk SDHCI_QUIRK2_DISABLE_HW_TIMEOUT, if the timeout count required by
> device is beyond the HW timer max count, we choose SW timer to avoid the HW timer timeout IRQ.
> 
> I don't know if I get it correctly.

Why can't drivers that want the behaviour just set the quirk?

Drivers that do not work with the quirk, do not have to set it.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ