linux-kernel - Re: [PATCH v1 2/2] mmc: sdhci: Use the SW timer when the HW timer cannot meet the timeout value required by the device

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: <37497369a4cf5f729e7b3e31727a7d64be5482db.camel@gmail.com>
Date:   Fri, 24 Sep 2021 23:33:56 +0200
From:   Bean Huo <huobean@...il.com>
To:     Adrian Hunter <adrian.hunter@...el.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 Fri, 2021-09-24 at 16:26 +0300, Adrian Hunter wrote:
> 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.


Adrian,

We cannot add this quirk to every host driver. This is the difference
on the device side. In addition, I don't know what the maximum hardware
timer budget for each host is. Even if you use the same SOC, the
maximum time budget on different platforms may be different.

Assume that the maximum timeout time supported by the hardware timer is
100 milliseconds, but the maximum data transmission time required by
the device is 150 milliseconds. In most cases, data transfer will not
take so long. 150 is the maximum time under extreme conditions. This
means that the device just needs to complete a data transfer within
>100ms and keep the data line busy. If we still use the HW timer, it
will trigger a DATA LINE timeout interrupt.

This patch does not affect scenarios where the hardware timer meets the
max data transmission time requirements of the device. It will still
use the hardware timer. Only when the device changes, will it switch to
using the SW timer.

Bean