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:   Fri, 27 Jul 2018 11:05:55 +0300
From:   Aapo Vienamo <avienamo@...dia.com>
To:     Stefan Agner <stefan@...er.ch>
CC:     Ulf Hansson <ulf.hansson@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Thierry Reding <thierry.reding@...il.com>,
        Jonathan Hunter <jonathanh@...dia.com>,
        "Adrian Hunter" <adrian.hunter@...el.com>,
        Mikko Perttunen <mperttunen@...dia.com>,
        <linux-mmc@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-tegra-owner@...r.kernel.org>
Subject: Re: [PATCH v2 02/10] dt-bindings: mmc: tegra: Add nvidia,only-1-8-v
 property

On Thu, 26 Jul 2018 15:05:55 +0200
Stefan Agner <stefan@...er.ch> wrote:

> On 26.07.2018 14:19, Aapo Vienamo wrote:
> > Add a property to mark controllers which operate at a 1.8 V fixed I/O
> > voltage.
> > 
> > This feature of the hardware needs to be signaled this way because it
> > cannot be probed at runtime or reliably derived from other properties.  
> 
> Is this really needed? Can we not use vqmmc to determine which voltage
> the controller runs on?
> 
> There is already some precedence in the SDHCI core to determine which
> voltage levels are supported:
> https://lkml.org/lkml/2018/7/5/342

This property is introduced to solve a slightly different issue. The
thing is that supplying a fixed voltage SDHCI controller from a variable
regulator is still a valid configuration. Which means that testing the
capabilities of the regulator doesn't actually describe the SDHCI
controller itself.

In practice this property is used to communicate whether pad
reconfiguration and voltage switching needs to be performed or not. This
cannot be determined from the absence or presence of the pinctrl
properties either because they naturally won't be there on older dtbs.

The logic behind this goes like this: if this property is present,
there's no need to perform pad or regulator reconfiguration and UHS
modes can be enabled. If this property is missing then valid pinctrl and
regulator properties are required to enable UHS signaling. This is
implemented in tegra_sdhci_is_uhs_valid() in "[PATCH v2 03/10] mmc:
tegra: Reconfigure pad voltages during voltage switching"

 -Aapo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ