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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 12 Dec 2019 15:56:56 +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 Wed, Dec 11, 2019 at 10:42:43PM +0000, Kieran Bingham wrote:
> On 09/12/2019 16:37, Mark Brown wrote:

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

> Ohh eep, I just re-read my description, and I don't think I described my
> intention very well at all. (or at all!)

> I wouldn't want to have just a half baked struct regulator_dev on it's
> own ... I was more wondering if we can kick the core driver framework to
> fully probe this regulator (which would thus create the required
> regulator_dev structures). It was more a question of can we guide the
> core driver framework that it really needs to probe this device
> immediately ...

Oh, I see.  Last time I looked at this in any detail the driver core did
probe things pretty much immediately when it got a new driver to match a
device (or vice versa), some existing MFDs rely on that.

> I was sort of wondering if something like this could optimise away some
> of the -EPROBE_DEFER iterations at a more global level, but I don't know
> how or if that would work anyway.

In theory someone could try to do some sort of sorting with the DT
graph, people keep talking about it but nobody's done anything that I'm
aware of.

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