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: <CAA8EJpoQ8O_atu9K=eG+NLQ_Ei64qvcQ6GoYyJjxJ_DGH2D2+Q@mail.gmail.com>
Date: Thu, 1 Feb 2024 06:38:17 +0200
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Chukun Pan <amadeus@....edu.cn>
Cc: andersson@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org, 
	konrad.dybcio@...aro.org, krzysztof.kozlowski+dt@...aro.org, 
	linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	robh+dt@...nel.org
Subject: Re: [PATCH 1/3] arm64: dts: qcom: ipq6018: separate CPU OPP tables

On Thu, 1 Feb 2024 at 06:00, Chukun Pan <amadeus@....edu.cn> wrote:
>
> Hi, Dmitry
> > Straight to the board files, please, no need for additional includes.
>
> Is it possible to move the mp5496 node to mp5496.dtsi?
> Because ipq9574 also uses this mp5496 pmic.
>
> &rpm_requests {
>         regulators {
>                 compatible = "qcom,rpm-mp5496-regulators";
>
>                 mp5496_s1: s1 {
>                         regulator-min-microvolt = <725000>;
>                         regulator-max-microvolt = <1075000>;
>                         status = "disabled";
>                 };
>
>                 mp5496_s2: s2 {
>                         regulator-min-microvolt = <725000>;
>                         regulator-max-microvolt = <1062500>;
>                         status = "disabled";
>                 };
>
>                 mp5496_l2: l2 {
>                         regulator-min-microvolt = <1800000>;
>                         regulator-max-microvolt = <3300000>;
>                         status = "disabled";
>                 };
>         };
> };

Usually this is a bad idea, the regulator boundaries are board specific.

>
> > From your patches I had the feeling that you still want to limit the
> > high-frequency OPP entries if there is no PMIC.
>
> Sorry for this misunderstanding, the cpu max frequency is determined
> by the cpu_speed_bin. It's just that the efuse of the board I have
> without pmic are all 1.2GHz.

Ack, sounds good then.

-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ