linux-kernel - Re: [PATCH V2] arm64: dts: fix drive strength macros as per FSD HW UM

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: <fa7c6054-7076-299d-ed0f-9e4fc0ffc194@linaro.org>
Date:   Tue, 11 Oct 2022 16:58:28 -0400
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        alim.akhtar@...sung.com, chanho61.park@...sung.com,
        linus.walleij@...aro.org, pankaj.dubey@...sung.com
Cc:     devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org
Subject: Re: [PATCH V2] arm64: dts: fix drive strength macros as per FSD HW UM

On 11/10/2022 04:03, Padmanabhan Rajanbabu wrote:
> Drive strength macros defined for FSD platform is not reflecting actual
> name and values as per HW UM. FSD SoC pinctrl has following four levels of

s/name/names/

> drive-strength and their corresponding values:
> Level-1 <-> 0
> Level-2 <-> 1
> Level-4 <-> 2
> Level-6 <-> 3
> 
> The commit 684dac402f21 ("arm64: dts: fsd: Add initial pinctrl support")
> used drive strength macros defined for Exynos4 SoC family. For some IPs
> the macros values of Exynos4 matched and worked well, but Exynos4 SoC
> family drive-strength (names and values) is not exactly matching with
> FSD SoC.
> 
> Fix the drive strength macros to reflect actual names and values given
> in FSD HW UM. This also ensures that the existing peripherals in device
> tree file is using correct drive strength MACROs to function as
> expected.
> 
> Fixes: 684dac402f21 ("arm64: dts: fsd: Add initial pinctrl support")
> Signed-off-by: Padmanabhan Rajanbabu <p.rajanbabu@...sung.com>
> ---

Rest of commit msg looks ok.

>  arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi | 34 +++++++++++-----------
>  arch/arm64/boot/dts/tesla/fsd-pinctrl.h    |  6 ++--
>  2 files changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi b/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
> index d0abb9aa0e9e..e3852c946352 100644
> --- a/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
> +++ b/arch/arm64/boot/dts/tesla/fsd-pinctrl.dtsi
> @@ -55,14 +55,14 @@
>  		samsung,pins = "gpf5-0";
>  		samsung,pin-function = <FSD_PIN_FUNC_2>;
>  		samsung,pin-pud = <FSD_PIN_PULL_NONE>;
> -		samsung,pin-drv = <FSD_PIN_DRV_LV2>;
> +		samsung,pin-drv = <FSD_PIN_DRV_LV4>;
>  	};
>  
>  	ufs_refclk_out: ufs-refclk-out-pins {
>  		samsung,pins = "gpf5-1";
>  		samsung,pin-function = <FSD_PIN_FUNC_2>;
>  		samsung,pin-pud = <FSD_PIN_PULL_NONE>;
> -		samsung,pin-drv = <FSD_PIN_DRV_LV2>;
> +		samsung,pin-drv = <FSD_PIN_DRV_LV4>;
>  	};
>  };
>  
> @@ -239,105 +239,105 @@
>  		samsung,pins = "gpb6-1";
>  		samsung,pin-function = <FSD_PIN_FUNC_2>;
>  		samsung,pin-pud = <FSD_PIN_PULL_UP>;
> -		samsung,pin-drv = <FSD_PIN_DRV_LV2>;
> +		samsung,pin-drv = <FSD_PIN_DRV_LV4>;
>  	};
>  
>  	pwm1_out: pwm1-out-pins {
>  		samsung,pins = "gpb6-5";
>  		samsung,pin-function = <FSD_PIN_FUNC_2>;
>  		samsung,pin-pud = <FSD_PIN_PULL_UP>;
> -		samsung,pin-drv = <FSD_PIN_DRV_LV2>;
> +		samsung,pin-drv = <FSD_PIN_DRV_LV4>;
>  	};
>  
>  	hs_i2c0_bus: hs-i2c0-bus-pins {
>  		samsung,pins = "gpb0-0", "gpb0-1";
>  		samsung,pin-function = <FSD_PIN_FUNC_2>;
>  		samsung,pin-pud = <FSD_PIN_PULL_UP>;
> -		samsung,pin-drv = <FSD_PIN_DRV_LV1>;
> +		samsung,pin-drv = <FSD_PIN_DRV_LV4>;

You are now changing both the value for register and the meaning (name).
Your commit msg indicated that the names are not correct, not the
values. Based on the commit msg, I expect the DTBs are the same. Are
they? If not, it these are two different commits with their own
explanations/reasoning.

Best regards,
Krzysztof