linux-kernel - Re: [PATCH v3 3/7] PCI: imx6: Fix the regulator dump when link never came up

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]

Message-ID: <YXqOcAIO2aYkr1sM@sirena.org.uk>
Date:   Thu, 28 Oct 2021 12:50:08 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Richard Zhu <hongxing.zhu@....com>
Cc:     Francesco Dolcini <francesco.dolcini@...adex.com>,
        "l.stach@...gutronix.de" <l.stach@...gutronix.de>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "jingoohan1@...il.com" <jingoohan1@...il.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: Re: [PATCH v3 3/7] PCI: imx6: Fix the regulator dump when link never
 came up

On Thu, Oct 28, 2021 at 06:50:58AM +0000, Richard Zhu wrote:

> > I would be really surprised to see PCI hardware that was able to support a
> > supply being physically absent, and this use of _is_enabled() is quite
> > simply not how any of this is supposed to work in the regulator API even
> > for regulators that can be optional.

> [Richard Zhu] Actually, this regulator is one GPIO fixed regulator.
> Controlled by SW to turn on (GPIO high) or turn off (GPIO low) the supply.
> In some boards designs, this supply might be always on(GPIO high).
> So, in point of SW driver view, this regulator is optional.

No, it's not.  The regulator API supports the systems where the
regualtor is always on perfectly well, the client driver should not need
to do anything to support them.

> > Perhaps it's not causing problems in this design but if the supply is ever
> > shared with anything else then the software will run into trouble.
> > There will also be problems with the error handling on a system where
> > the regulator needs to be controlled.

> [Richard Zhu] This GPIO fixed regulator is only used by controller driver.
> It makes sense to disable the enabled regulator when driver probe is failed.

The driver should undo any enables it did itself, it should not undo any
enables that anything else did which means it should never be basing
decisions on regulator_is_enabled().  While the regulator may not be
shared in the particular board you're looking at it may be shared in
other systems.

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