linux-kernel - Re: [RFC] regulator: Shared regulators (configured by bootloader)

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, 15 May 2017 16:17:13 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Nayak, Rajendra" <rnayak@...eaurora.org>,
        Stephen Boyd <sboyd@...eaurora.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Serge Broslavsky <serge.broslavsky@...aro.org>
Subject: Re: [RFC] regulator: Shared regulators (configured by bootloader)

On 14-05-17, 18:30, Mark Brown wrote:
> On Mon, May 08, 2017 at 03:51:02PM +0530, Viresh Kumar wrote:
> 
> > I am looking to solve a problem faced by some of the Qualcomm
> > platforms and want your suggestions on how should we fix it. One of my
> > ex-colleague tried to solve [1] this problem but that thread never
> > concluded (and I don't really agree with the solution it offered).
> 
> Please engage with the feedback I offered then.  I see no point in
> repeating myself here, I'm just going to provide the same feedback as
> before and if I'm going to be ignored (which appears to be the case) it
> doesn't seem like it's worth the effort.

I didn't ignore any of that. Most of the discussions then happened around the
solution which Pingbo tried to implement (boot-protection flag). And that had
obvious flaws as it depended on the state of the kernel to be known
(booting/booted). And that will never work, as you pointed out then, because of
the way kernel works (specially with modules).

You said this in one of the replies [1]:

> I think you need to be looking at some combination of getting the
> devices you're interested in started up early and more precisely
> describing the end result you're trying to achieve.  The issues with
> probe deferral do seem related here, it's another symptom of not really
> making any decisions about init ordering and so sometimes making bad
> ones.

I don't think we should depend on the order in which the devices get added. This
is going to break for sure.

I have some idea about the end-result we want to achieve (will take LCD as an
example here):
- The regulator should always fulfill the requirement of the LCD device set from
  the bootloader, until a point where the kernel driver has taken over.
- If the LCD kernel driver never turns up, then the regulator shall continue
  satisfying the requirements set from the bootloader. Even if that means that
  some devices may not get what they request for and perform badly. Someone
  needs to fix the LCD driver and make sure it comes up.


I failed to find any other workable solution that anyone may have suggested in
those email threads. Can you please point me to those (if any)?

Thanks.

-- 
viresh

[1] https://marc.info/?l=linux-kernel&m=146540618625247