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: <CAPDyKFrBEoJdJuh9KyBf8MNuAXTy9HCr4GfKPRZpa61FaZHYHA@mail.gmail.com>
Date:   Thu, 16 Apr 2020 17:26:24 +0200
From:   Ulf Hansson <ulf.hansson@...aro.org>
To:     Veerabhadrarao Badiganti <vbadigan@...eaurora.org>
Cc:     Adrian Hunter <adrian.hunter@...el.com>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arm-msm <linux-arm-msm@...r.kernel.org>,
        Andy Gross <agross@...nel.org>
Subject: Re: [PATCH V1 2/4] mmc: sdhci-msm: Enable MMC_CAP_NEED_RSP_BUSY host capability

On Thu, 16 Apr 2020 at 16:49, Veerabhadrarao Badiganti
<vbadigan@...eaurora.org> wrote:
>
> Hi Ulf,
>
> On 4/16/2020 5:46 PM, Ulf Hansson wrote:
> > On Sun, 12 Apr 2020 at 17:54, Veerabhadrarao Badiganti
> > <vbadigan@...eaurora.org> wrote:
> >> sdhci-msm controller requires the R1B response for commands that
> >> has this response associated with them.
> >>
> >> So enable MMC_CAP_NEED_RSP_BUSY capability.
> > I assume this potentially should be considered as fix and tagged for stable?
> Yes Stable flag can be applied to this.
>
> Patch with MMC_CAP_WAIT_WHILE_BUSY cap also needed besides this.
> Shall I push V2 with stable flag?

Ah, so maybe squash both into one patch to simplify for stable?

Yes, please add a stable tag in v2.

>
> > Another question, if there is there an upper limit of the busy timeout
> > in the HW (cmd->busy_timeout) or does the driver use a software
> > timeout that is adjustable?
>
> The max supported h.w busy timeout value on qcom h/w 21sec.

Alright, that sounds like it should be sufficient for most cases. But
perhaps not for eMMC sanitize.

How do you cope with the situation when the R1B response is passed to
the driver and the cmd->busy_timeout exceeds the 21s?

[...]

Kind regards
Uffe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ