linux-kernel - Re: [PATCH v2 02/10] dt-bindings: mmc: tegra: Add nvidia,only-1-8-v property

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: <20180730232441.GA17560@rob-hp-laptop>
Date:   Mon, 30 Jul 2018 17:24:41 -0600
From:   Rob Herring <robh@...nel.org>
To:     Aapo Vienamo <avienamo@...dia.com>
Cc:     Stefan Agner <stefan@...er.ch>,
        Ulf Hansson <ulf.hansson@...aro.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 Fri, Jul 27, 2018 at 11:05:55AM +0300, Aapo Vienamo wrote:
> 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.

The regulator constraints should reflect this. The constraints aren't 
the capabilities of the regulator, but the limits on what it is 
supplying.

> 
> 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