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 Feb 2024 10:19:09 +0100
From: Peter Rosin <peda@...ntia.se>
To: Siddharth Vadapalli <s-vadapalli@...com>, nm@...com, vigneshr@...com,
 kristo@...nel.org, robh@...nel.org, krzysztof.kozlowski+dt@...aro.org,
 conor+dt@...nel.org, afd@...com, gregkh@...uxfoundation.org
Cc: devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, c-vankar@...com, srk@...com
Subject: Re: [PATCH v5] arm64: dts: ti: k3-j784s4-main: Fix mux-reg-masks in
 serdes_ln_ctrl

Hi!

2024-02-13 at 09:03, Siddharth Vadapalli wrote:
> From: Chintan Vankar <c-vankar@...com>
> 
> Change offset in mux-reg-masks property for serdes_ln_ctrl node
> since reg-mux property is used in compatible.
> 
> Fixes: 2765149273f4 ("mux: mmio: use reg property when parent device is not a syscon")
> Signed-off-by: Chintan Vankar <c-vankar@...com>
> Acked-by: Andrew Davis <afd@...com>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@...com>
> ---
> Hello,
> 
> This patch is based on linux-next tagged next-20240213.
> The v4 of this patch is a part of the series at:
> https://lore.kernel.org/r/20240131101441.1362409-1-c-vankar@ti.com/
> 
> Since the v4 series mentioned above has open comments on the other
> patches in the series, this patch is being posted separately to unblock
> other dependent series which rely on the fix implemented by this patch.
> 
> Changes since v4:
> - Rebased patch on linux-next tagged next-20240213.
> 
> Regards,
> Siddharth.
> 
>  arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi | 12 ++++++------
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 3cb964982792..3b7f0eca977b 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -52,12 +52,12 @@ serdes_ln_ctrl: mux-controller@...0 {
>  			compatible = "reg-mux";
>  			reg = <0x00004080 0x30>;
>  			#mux-control-cells = <1>;
> -			mux-reg-masks = <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */
> -					<0x4088 0x3>, <0x408c 0x3>, /* SERDES0 lane2/3 select */
> -					<0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */
> -					<0x4098 0x3>, <0x409c 0x3>, /* SERDES1 lane2/3 select */
> -					<0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */
> -					<0x40a8 0x3>, <0x40ac 0x3>; /* SERDES2 lane2/3 select */
> +			mux-reg-masks = <0x0 0x3>, <0x4 0x3>, /* SERDES0 lane0/1 select */
> +					<0x8 0x3>, <0xc 0x3>, /* SERDES0 lane2/3 select */
> +					<0x10 0x3>, <0x14 0x3>, /* SERDES1 lane0/1 select */
> +					<0x18 0x3>, <0x1c 0x3>, /* SERDES1 lane2/3 select */
> +					<0x20 0x3>, <0x24 0x3>, /* SERDES2 lane0/1 select */
> +					<0x28 0x3>, <0x2c 0x3>; /* SERDES2 lane2/3 select */
>  			idle-states = <J784S4_SERDES0_LANE0_PCIE1_LANE0>,
>  				      <J784S4_SERDES0_LANE1_PCIE1_LANE1>,
>  				      <J784S4_SERDES0_LANE2_IP3_UNUSED>,

Ouch. I suspect there is a similar problem in
arch/arm64/boot/dts/ti/k3-j721e-mcu-wakeup.dtsi:


	fss: bus@...00000 {
		compatible = "simple-bus";
		reg = <0x0 0x47000000 0x0 0x100>;
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		hbmc_mux: mux-controller@...00004 {
			compatible = "reg-mux";
			reg = <0x00 0x47000004 0x00 0x2>;
			#mux-control-cells = <1>;
-			mux-reg-masks = <0x4 0x2>; /* HBMC select */
+			mux-reg-masks = <0x0 0x2>; /* HBMC select */
		};

Who knows what non-upstreamed devices and devicetrees are affected?
I guess we need to revert 2765149273f4 ("mux: mmio: use reg property
when parent device is not a syscon") unless someone sees a sane way
to fix this.

Cheers,
Peter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ