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: <c4a886d8-8389-2c50-a40b-e2965ef6c393@intel.com>
Date:   Fri, 25 Sep 2020 12:31:50 +0300
From:   Adrian Hunter <adrian.hunter@...el.com>
To:     Raul Rangel <rrangel@...omium.org>
Cc:     "Shah, Nehal-bakulchandra" <Nehal-bakulchandra.Shah@....com>,
        "Wang, Chris" <chris.wang@....com>,
        Akshu Agrawal <Akshu.Agrawal@....com>,
        Jisheng Zhang <jszhang@...vell.com>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        clang-built-linux@...glegroups.com,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-mmc@...r.kernel.org
Subject: Re: [PATCH v2] mmc: sdhci: Don't enable presets while tuning

On 18/09/20 8:57 pm, Raul Rangel wrote:
> On Tue, Sep 1, 2020 at 4:54 AM Adrian Hunter <adrian.hunter@...el.com> wrote:
>>
>> On 24/08/20 9:21 pm, Raul E Rangel wrote:
>>> SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are
>>> used for DDR52. The HS400 retuning sequence is:
>>>
>>>     HS400->DDR52->HS->HS200->Perform Tuning->HS->HS400
>>>
>>> This means that when HS400 tuning happens, we transition through DDR52
>>> for a very brief period. This causes presets to be enabled
>>> unintentionally and stay enabled when transitioning back to HS200 or
>>> HS400.
>>>
>>> This patch prevents enabling presets while tuning is in progress.
>>
>> Preset value should not generally have to depend on tuning, so this
>> seems less than ideal.  Also I am not sure you can say some controllers
>> are not accidentally benefiting from the current situation.
>>
>> What about just letting drivers choose the timing modes that support
>> preset values?  e.g. using the change below, a driver could alter
>> host->preset_value_support as needed
> 
> Sorry for the late reply, I'm just getting back to this. I like the
> patch. I have a few other patches I'm
> going to push up soon. Do you want me to include this in the chain, or
> do you want to push it up?

I'm snowed.  You will have to do it I am afraid.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ