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]

Message-ID: <fb87c957-40e8-587e-5789-33b740f8326d@ideasonboard.com>
Date:   Wed, 11 Dec 2019 22:42:43 +0000
From:   Kieran Bingham <kieran.bingham@...asonboard.com>
To:     Mark Brown <broonie@...nel.org>
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)

Hi Mark,

On 09/12/2019 16:37, Mark Brown wrote:
> 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.

As long as we can defer and not break the other layers this could
potentially work.

Breaking the GMSL driver out to have it's own bus (generically for
serdes buses) and allowing the MAX9286 to probe fully before probing any
subdevices is another alternative suggestion I've had (but much more
work I think).

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

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.

> the system which will need special casing all over the place and
> doubtless be an ongoing source of bugs.

Indeed, I wasn't expecting to have some different case non-probed
regulator ...

Anyway, it's possibly a moot point I think - Niklas has suggested that
he can indeed resolve the -EPROBE_DEFER restrictions.

I'm not yet sure if we want to go full MFD yet ... so I've left this
feature out of my latest posting for the driver - and we'll discuss the
direction for solving this in our team.

Thanks again,
-- 
Regards
--
Kieran