linux-kernel - Re: [RFC PATCH v1 3/3] regulator: bd718x7: Support SNVS low power state

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:   Tue, 12 Feb 2019 16:08:31 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
Cc:     mazziesaccount@...il.com, Lee Jones <lee.jones@...aro.org>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Liam Girdwood <lgirdwood@...il.com>,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        heikki.haikola@...rohmeurope.com, mikko.mutanen@...rohmeurope.com,
        Robin Gong <yibin.gong@....com>,
        Elven Wang <elven.wang@....com>,
        Anson Huang <anson.huang@....com>
Subject: Re: [RFC PATCH v1 3/3] regulator: bd718x7: Support SNVS low power
 state

On Tue, Feb 12, 2019 at 04:19:38PM +0200, Matti Vaittinen wrote:
> read ROHM BD71837 / BD71847 specific device tree bindings for
> controlling the PMIC shutdown/reset states and voltages for
> different HW states. The PMIC was designed to be used with NXP
> i.MX8 SoC and it supports SNVS low power state which seems to
> be typical for NXP i.MX SoCs. However, when SNVS is used we must
> not allow SW to control enabling/disabling those regulators which
> are crucial for system to boot as there is a HW limitation which
> causes SW controlled regulators to be kept shut down after SNVS
> reset.
> 
> Allow setting the SNVS to be used as reset target state and allow
> marking those regulators which are critical for boot.

The general idea seems fine but I'm wondering if we should use the
existing bindings and just prevent any change with fixed configurations
- that *should* just be a case of picking appropriate constraints I
think.  Why does this need completely new properties other than
preventing the user from shooting themselves in the foot?

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)