linux-kernel - Re: [PATCH] arm64: dts: mediatek: mt8186: Add I2C arbiter clocks to i2c 1/2/5

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: <8414e0ccdb5f456877df06d4e5c6befff5463991.camel@mediatek.com>
Date:   Wed, 8 Nov 2023 06:56:08 +0000
From:   Yu-chang Lee (李禹璋) 
        <Yu-chang.Lee@...iatek.com>
To:     "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "angelogioacchino.delregno@...labora.com" 
        <angelogioacchino.delregno@...labora.com>
CC:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "wenst@...omium.org" <wenst@...omium.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "kernel@...labora.com" <kernel@...labora.com>,
        Allen-KH Cheng (程冠勲) 
        <Allen-KH.Cheng@...iatek.com>,
        "conor+dt@...nel.org" <conor+dt@...nel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>
Subject: Re: [PATCH] arm64: dts: mediatek: mt8186: Add I2C arbiter clocks to
 i2c 1/2/5

On Fri, 2023-10-20 at 09:55 +0200, AngeloGioacchino Del Regno wrote:
> The I2C busses 1, 2 and 5 have got a separated arbiter clock: add it
> to their respective nodes.
> 
> Fixes: 2e78620b1350 ("arm64: dts: Add MediaTek MT8186 dts and
> evaluation board and Makefile")
> Signed-off-by: AngeloGioacchino Del Regno <
> angelogioacchino.delregno@...labora.com>
> ---
>  arch/arm64/boot/dts/mediatek/mt8186.dtsi | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> index f04ae70c470a..af6f6687de35 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8186.dtsi
> @@ -1224,8 +1224,9 @@ i2c1: i2c@...08000 {
>  			      <0 0x10200200 0 0x100>;
>  			interrupts = <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
> 0>;
>  			clocks = <&imp_iic_wrap
> CLK_IMP_IIC_WRAP_AP_CLOCK_I2C1>,
> -				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>;
> -			clock-names = "main", "dma";
> +				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_I2C1_ARBITER>;
> +			clock-names = "main", "dma", "arb";
>  			clock-div = <1>;
>  			#address-cells = <1>;
>  			#size-cells = <0>;
> @@ -1238,8 +1239,9 @@ i2c2: i2c@...09000 {
>  			      <0 0x10200300 0 0x180>;
>  			interrupts = <GIC_SPI 107 IRQ_TYPE_LEVEL_HIGH
> 0>;
>  			clocks = <&imp_iic_wrap
> CLK_IMP_IIC_WRAP_AP_CLOCK_I2C2>,
> -				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>;
> -			clock-names = "main", "dma";
> +				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_I2C2_ARBITER>;
> +			clock-names = "main", "dma", "arb";
>  			clock-div = <1>;
>  			#address-cells = <1>;
>  			#size-cells = <0>;
> @@ -1280,8 +1282,9 @@ i2c5: i2c@...16000 {
>  			      <0 0x10200700 0 0x100>;
>  			interrupts = <GIC_SPI 354 IRQ_TYPE_LEVEL_HIGH
> 0>;
>  			clocks = <&imp_iic_wrap
> CLK_IMP_IIC_WRAP_AP_CLOCK_I2C5>,
> -				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>;
> -			clock-names = "main", "dma";
> +				 <&infracfg_ao CLK_INFRA_AO_AP_DMA>,
> +				 <&infracfg_ao
> CLK_INFRA_AO_I2C5_ARBITER>;
> +			clock-names = "main", "dma", "arb";
>  			clock-div = <1>;
>  			#address-cells = <1>;
>  			#size-cells = <0>;

In previous discussion[1], if the arbiter clock is not added into dts
node does trackpad lost its functionality before system suspend/resume?
And is this patch meant to solve the same issue in [1]?

Reply on behalf of our i2c PIC.

Sorry for late reply
Best Regards,
YuChang
[1]: 
https://lore.kernel.org/all/32d51e40-5d9c-47dd-bb62-2ccc811ac6dc@collabora.com/