linux-kernel - Re: Regulator probe on demand (or circular dependencies)

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:   Mon, 9 Dec 2019 16:37:55 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Kieran Bingham <kieran.bingham@...asonboard.com>
Cc:     Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
        Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Jacopo Mondi <jacopo@...ndi.org>,
        Niklas Söderlund 
        <niklas.soderlund@...natech.se>
Subject: Re: Regulator probe on demand (or circular dependencies)

On Fri, Dec 06, 2019 at 04:38:04PM +0000, Kieran Bingham wrote:

> The MAX9286 also exposes 2 GPIO pins, as such I have configured the
> MAX9286 driver [1] to expose a gpio-chip [2].

So this seems like a MFD then?  The nice thing about using the MFD
subsystem is that it means that the drivers for the various subsystems
on the device can instantiate in any order and defer separately without
interfering with each other which seems like it's the issue here.

>  - is there anything I can do here within regulator_dev_lookup() to
>    attempt creating the regulator_dev 'on-demand' when
>    of_find_regulator_by_node(node) returns empty? (or is that crazy, and
>    just a rabbit-hole?)

This seems like a terrible idea, you'll have a half baked regulator in
the system which will need special casing all over the place and
doubtless be an ongoing source of bugs.

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