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: Sun, 24 Mar 2024 11:45:09 +0100
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Pratham Patel <prathampatel@...fossguy.com>, robh@...nel.org
Cc: krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org, heiko@...ech.de,
 devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] arm64: dts: rockchip: disable analog audio for
 rock-5b

On 24/03/2024 07:28, Pratham Patel wrote:
> The addition of `of: property: fw_devlink: Fix stupid bug in remote-endpoint parsing`

Please refer to commits using commit sha () syntax, as mentioned in
submitting patches.

> has surfaced an issue with the analog audio property in the devicetree
> for the rock-5b. Booting kernels v6.7.9+ and v6.8.0+ would cause the
> following call trace:
> 
> [   21.595068] Call trace:
> [   21.595288]  smp_call_function_many_cond+0x174/0x5f8
> [   21.595728]  on_each_cpu_cond_mask+0x2c/0x40
> [   21.596109]  cpuidle_register_driver+0x294/0x318
> [   21.596524]  cpuidle_register+0x24/0x100
> [   21.596875]  psci_cpuidle_probe+0x2e4/0x490
> [   21.597247]  platform_probe+0x70/0xd0
> [   21.597575]  really_probe+0x18c/0x3d8
> [   21.597905]  __driver_probe_device+0x84/0x180
> [   21.598294]  driver_probe_device+0x44/0x120
> [   21.598669]  __device_attach_driver+0xc4/0x168
> [   21.599063]  bus_for_each_drv+0x8c/0xf0
> [   21.599408]  __device_attach+0xa4/0x1c0
> [   21.599748]  device_initial_probe+0x1c/0x30
> [   21.600118]  bus_probe_device+0xb4/0xc0
> [   21.600462]  device_add+0x68c/0x888
> [   21.600775
> ]  platform_device_add+0x19c/0x270
> [   21.601154]  platform_device_register_full+0xdc/0x178
> [   21.601602]  psci_idle_init+0xa0/0xc8
> [   21.601934]  do_one_initcall+0x60/0x290
> [   21.602275]  kernel_init_freeable+0x20c/0x3e0
> [   21.602664]  kernel_init+0x2c/0x1f8
> [   21.602979]  ret_from_fork+0x10/0x20
> 
> This is a temporary workaround to at least have the SBC boot. There are
> a few more SBCs that _might_ have this issue. I suspect that the
> rock-5a and nanopc-t6 might also have this issue but I do not own either
> board to verify this claim, yet.
> 
> Closes: https://lore.kernel.org/regressions/28S1EMw5YOnQIBpQ8_qaZZ6c9Go-j6-lLuWWbRpe6-MtRUd7Ay-uXq8JHbVVtJv3LzpxjI8jYg7ukNntbN22PVV-hOWbuTY8FNWgvM4zSwI=@thefossguy.com/T/#m69eedea6fbcb0591d54a9ccd478c2782ef045547
> 
> Signed-off-by: Pratham Patel <prathampatel@...fossguy.com>
> ---
>  .../boot/dts/rockchip/rk3588-rock-5b.dts      | 110 +++++++++---------
>  1 file changed, 57 insertions(+), 53 deletions(-)
> 
> diff --git a/arch/arm64/boot/d
> ts/rockchip/rk3588-rock-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> index 1fe8b2a0e..6d3b9f52c 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> @@ -20,22 +20,24 @@ chosen {
>  		stdout-path = "serial2:1500000n8";
>  	};
>  
> -	analog-sound {
> -		compatible = "audio-graph-card";
> -		label = "rk3588-es8316";
> -
> -		widgets = "Microphone", "Mic Jack",
> -			  "Headphone", "Headphones";
> -
> -		routing = "MIC2", "Mic Jack",
> -			  "Headphones", "HPOL",
> -			  "Headphones", "HPOR";
> -
> -		dais = <&i2s0_8ch_p0>;
> -		hp-det-gpio = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> -		pinctrl-names = "default";
> -		pinctrl-0 = <&hp_detect>;
> -	};
> +	/*
> +	 *analog-sound {
> +	 *	compatible = "audio-graph-card";
> +	 *	label = "rk3588-es8316";

Do not comment out code. Instead disable the nodes and provide
appropriate comment describing reason.

Anyway, this does not look like correct solution. DTS is independent of
OS, so bug in fwlink does not matter for DTS. Either DTS is a correct
hardware representation or not.

Best regards,
Krzysztof


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ