linux-kernel - Re: [PATCH v1] Revise duty cycle for SMB9 and SMB10

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] [day] [month] [year] [list]

Date: Tue, 02 Apr 2024 15:11:55 +1030
From: Andrew Jeffery <andrew@...econstruct.com.au>
To: Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>, patrick@...cx.xyz, Rob
 Herring <robh@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Joel Stanley <joel@....id.au>
Cc: devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-aspeed@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1] Revise duty cycle for SMB9 and SMB10

On Mon, 2024-04-01 at 17:05 +0800, Delphine CC Chiu wrote:
> ARM: dts: aspeed: yosemite4:
> Revise duty cycle for SMB9 and SMB10 to 40:60
> To meet 400kHz-i2c clock low time spec (> 1.3 us).
> 
> Signed-off-by: Delphine CC Chiu <Delphine_CC_Chiu@...ynn.com>
> ---
>  arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> index 64075cc41d92..b3a2aa8f53a5 100644
> --- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> +++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-yosemite4.dts
> @@ -257,6 +257,7 @@ power-sensor@40 {
>  &i2c8 {
>  	status = "okay";
>  	bus-frequency = <400000>;
> +	i2c-clk-high-min-percent = <40>;

A grep of the 6.9-rc2 tree doesn't turn up any mention of this property
name.

More work needs to be done if this is meant to have any effect.

What tree are you developing your patches against? If you're sending
them upstream then you must do your work (and test) in the context of
upstream.

Andrew