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]
Date:   Tue, 13 Dec 2022 15:54:05 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Brian Masney <bmasney@...hat.com>
Cc:     andersson@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        konrad.dybcio@...aro.org, robh+dt@...nel.org,
        johan+linaro@...nel.org, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        ahalaney@...hat.com, echanude@...hat.com, quic_shazhuss@...cinc.com
Subject: Re: [PATCH 1/4] arm64: dts: qcom: sc8280xp: rename i2c5 to i2c21

On Mon, Dec 12, 2022 at 01:23:11PM -0500, Brian Masney wrote:
> According to the downstream 5.4 kernel sources for the sa8540p,
> i2c@...000 is labeled i2c bus 21, not 5. The interrupts and clocks
> also match. Let's go ahead and correct the name that's used in the
> three files where this is listed.
> 
> Signed-off-by: Brian Masney <bmasney@...hat.com>
> Fixes: 152d1faf1e2f3 ("arm64: dts: qcom: add SC8280XP platform")
> Fixes: ccd3517faf183 ("arm64: dts: qcom: sc8280xp: Add reference device")
> Fixes: 32c231385ed43 ("arm64: dts: qcom: sc8280xp: add Lenovo Thinkpad X13s devicetree")

> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index 109c9d2b684d..875cc91324ce 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -827,7 +827,7 @@ qup2_uart17: serial@...000 {
>  				status = "disabled";
>  			};
>  
> -			qup2_i2c5: i2c@...000 {
> +			qup2_i2c21: i2c@...000 {

Note that the node is labelled qup2_i2c5 and not qup_i2c5.

That is, the QUP nodes are labelled using two indices, and specifically

	qup2_i2c5

would be another name for

	qup_i2c21

if we'd been using such a flat naming scheme (there are 8 engines per
QUP).

So there's nothing wrong with how these nodes are currently named, but
mixing the two scheme as you are suggesting would not be correct.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ