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]
Date:   Wed, 14 Jun 2017 09:25:00 +0200
From:   Richard Leitner <richard.leitner@...data.com>
To:     Ulf Hansson <ulf.hansson@...aro.org>,
        Linus Walleij <linus.walleij@...aro.org>
CC:     Bart Van Assche <bart.vanassche@...disk.com>,
        Luca Porzio <lporzio@...ron.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Shawn Lin <shawn.lin@...k-chips.com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Jaehoon Chung <jh80.chung@...sung.com>,
        "linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        Richard Leitner <dev@...l1n.net>
Subject: Re: [PATCH v2] mmc: core: add mmc-card hardware reset enable support

On 04/11/2017 12:43 PM, Ulf Hansson wrote:
> On 11 April 2017 at 10:17, Linus Walleij <linus.walleij@...aro.org> wrote:
>> On Tue, Apr 11, 2017 at 9:31 AM, Richard Leitner
>> <richard.leitner@...data.com> wrote:
>>
>>> Some eMMCs disable their hardware reset line (RST_N) by default. To enable
>>> it the host must set the corresponding bit in ECSD. An example for such
>>> a device is the Micron MTFCxGACAANA-4M.
>>>
>>> This patch adds a new mmc-card devicetree property to let the host enable
>>> this feature during card initialization.
>>>
>>> Signed-off-by: Richard Leitner <richard.leitner@...data.com>
>>
>> Do we know *WHY* these cards disable their hardware reset lines?
> 
> Allow me to make a guess. In case the reset isn't enabled, the
> internal eMMC card firmware don't monitor the pin for the reset. I
> guess that could makes sense if SoC vendors has failed to properly
> connect the pin, avoiding the eMMC card to be reset when it shouldn't.
> 
>> If it is just some random over-cautious panic thing we might consider
>> just force re-enableing it, maybe with a warning in the dmesg, so we can
>> always reset the card. No DT property needed.
> 
> There is actually already a DT property "cap-mmc-hw-reset"
> (MMC_CAP_HW_RESET), which tells whether the eMMC reset is supported by
> the host.
> 
> Perhaps we can consider to force-enabling it for the eMMC card, when
> this property is set for the mmc host!? At least, inventing yet
> another binding doesn't make sense to me.

IMHO setting this (permanent) configuration bit should be done
explicitly and not within another DT property. Otherwise somebody may
accidentally set this configuration by (for example) including a dtsi
which has cap-mmc-hw-reset configured.

Nonetheless if the majority agrees to implicitly set it when
"cap-mmc-hw-reset" is configured I'm fine with that too.

Another possibility is to don't include it in the kernel at all and
therefore require the mmc userspace program to configure it...?

> 
>> Putting some people who work for eMMC vendors in the To: line so they
>> can say if they know about this.
> 
> Yes, let's see what they say about it.

Any news/comments?

kind regards,
Richard.L

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ