linux-kernel - Re: [RFC PATCH] PM / OPP: Always expose one supply in debugfs

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] [day] [month] [year] [list]

Message-ID: <20181211112722.vu2zrpcdw3ez3kag@vireshk-i7>
Date:   Tue, 11 Dec 2018 16:57:22 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Quentin Perret <quentin.perret@....com>
Cc:     vireshk@...nel.org, nm@...com, sboyd@...nel.org,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] PM / OPP: Always expose one supply in debugfs

On 11-12-18, 09:49, Quentin Perret wrote:
> So, on Juno we do get voltage numbers from firmware, and those get
> registered properly in PM_OPP, exactly like for Hikey960. So it's
> probably the same problem in both cases.
> 
> FWIW, this is what I get on juno with my 'fix' applied:
> 
>   $ cat /sys/kernel/debug/opp/cpu0/*/supply-0/u_volt_target
>   820000
>   850000
>   900000
>   950000
>   1000000
> 
> > Anyway, this should still be fixed irrespective of the "cpu-supply" property.
> > The other fix you mentioned about setting opp_table->regulator_count to 1 is
> > actually the right thing to do but the fix may require changes at multiple
> > places. I can help writing a patch for that if you want, else I am open to you
> > giving it a shot :)
> 
> You'll definitely know the code better than me so if you have a patch in
> mind, please don't hesitate. I'll be happy to test it on my two boards
> here :-)

Sent some patches, please give them a try.

-- 
viresh