linux-kernel - Re: [RESEND PATCH v4 4/4] arm64: dts: Add MediaTek MT8188 dts and evaluation board and Makefile

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: <7b2ab315d10e0e62fdf5597d0ca91346aa3db1df.camel@mediatek.com>
Date:   Tue, 17 Oct 2023 07:48:44 +0000
From:   Jason-ch Chen (陳建豪) 
        <Jason-ch.Chen@...iatek.com>
To:     "amergnat@...libre.com" <amergnat@...libre.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
CC:     "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "wenst@...omium.org" <wenst@...omium.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "nfraprado@...labora.com" <nfraprado@...labora.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RESEND PATCH v4 4/4] arm64: dts: Add MediaTek MT8188 dts and
 evaluation board and Makefile

Hi Alexandre,

On Mon, 2023-10-16 at 11:36 +0200, Alexandre Mergnat wrote:
>  	 
> 
..snip..
> > +&mt6359_vbbck_ldo_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vcn33_2_bt_ldo_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vcore_buck_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vgpu11_buck_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vpu_buck_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vrf12_ldo_reg {
> > +regulator-always-on;
> > +};
> > +
> > +&mt6359_vufs_ldo_reg {
> > +regulator-always-on;
> > +};
> > +
> 
> This is a lot of always-on regulator.
> Is it possible to justify them? Maybe some of them should be just 
> included into a relevent node ? For example,
> "mt6359_vcn33_2_bt_ldo_reg" 
> could be into the bluetooth node right ?
> 
> Angelo already wrote me a feedback about that in the MT8365 serie:
> 
https://lore.kernel.org/all/ff7292f0-9055-1787-2543-e219fe30dddf@collabora.com/

Thank you for pointing out the problem.

The mt6359_vbbck_ldo_reg and mt6359_vcn33_2_bt_ldo_reg are not
necessary in the evb. The mt6359_vufs_ldo_reg is already included in
the mmc0 node. These nodes will be removed in the next version.

The remain power rails do not have specific users in linux kernel, but
they are powered by CPU/CORE/analog and are registered in the regulator
framework. The regulator framework has a power mechanism that shuts
down power rails with use count is 0 after 30 seconds of startup, and
then CPU/The power of CORE/analog cannot be turned off, so the
regulator-always-on property is added to the dts node.

> 
> > +&nor_flash {
> > +status = "okay";
> > +pinctrl-names = "default";
> > +pinctrl-0 = <&nor_pins_default>;
> > +#address-cells = <1>;
> > +#size-cells = <0>;
> 
..snip..
> 
> -- 
> Regards,
> Alexandre

Regards,
Jason