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]
Message-ID: <4ab70c6a.8be.198f47da494.Coremail.luyulin@eswincomputing.com>
Date: Fri, 29 Aug 2025 14:22:11 +0800 (GMT+08:00)
From: luyulin@...incomputing.com
To: "Niklas Cassel" <cassel@...nel.org>
Cc: "Rob Herring" <robh@...nel.org>, dlemoal@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, linux-ide@...r.kernel.org,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	vkoul@...nel.org, kishon@...nel.org, linux-phy@...ts.infradead.org,
	ningyu@...incomputing.com, zhengyu@...incomputing.com,
	linmin@...incomputing.com, huangyifeng@...incomputing.com,
	fenglin@...incomputing.com, lianghujun@...incomputing.com
Subject: Re: Re: Re: [PATCH v2 1/3] dt-bindings: ata: eswin: Document for
 EIC7700 SoC ahci


> On Thu, Aug 28, 2025 at 06:22:40PM +0800, luyulin@...incomputing.com wrote:
> > 
> > Do you mean that ports-implemented should be removed from the dts,
> > and the corresponding register should be configured by the firmware
> > (which is U-Boot on the HiFive Premier P550 board)? Is this understanding correct?
> > If so, when the driver is removed, a reset will be triggered,
> > causing the configuration of this register to be lost,
> > which will result in an error when insmod the driver again.
> 
> My 50 cents,
> 
> if the ports implemented register gets reset from the reset_control_reset()
> in ahci_platform_assert_rsts(), then it seems like having ports-implemented
> in device tree is acceptable.
> 

In our design, the ports implemented register gets reset from the ahci_platform_assert_rsts().

> There are a bunch of device trees that have this already:
> arch/arm/boot/dts/qcom/qcom-apq8064.dtsi:                       ports-implemented = <0x1>;
> arch/arm/boot/dts/qcom/qcom-ipq8064-v1.0.dtsi:                  ports-implemented = <0x1>;
> arch/arm/boot/dts/qcom/qcom-ipq8064-v2.0.dtsi:  ports-implemented = <0x1>;
> arch/arm/boot/dts/samsung/exynos5250.dtsi:                      ports-implemented = <0x1>;
> arch/arm/boot/dts/socionext/uniphier-pro4.dtsi:                 ports-implemented = <1>;
> arch/arm/boot/dts/socionext/uniphier-pro4.dtsi:                 ports-implemented = <1>;
> arch/arm/boot/dts/socionext/uniphier-pxs2.dtsi:                 ports-implemented = <1>;
> arch/arm/boot/dts/st/stih407-family.dtsi:                       ports-implemented = <0x1>;
> arch/arm/boot/dts/st/stih407-family.dtsi:                       ports-implemented = <0x1>;
> arch/arm/boot/dts/ti/omap/dra7-l4.dtsi:                         ports-implemented = <0x1>;
> arch/arm/boot/dts/ti/omap/omap5-l4.dtsi:                                ports-implemented = <0x1>;
> arch/arm64/boot/dts/mediatek/mt7622.dtsi:               ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3568.dtsi:               ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk356x-base.dtsi:          ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk356x-base.dtsi:          ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3576.dtsi:                       ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3576.dtsi:                       ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi:          ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi:          ports-implemented = <0x1>;
> arch/arm64/boot/dts/rockchip/rk3588-extra.dtsi:         ports-implemented = <0x1>;
> arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi:                       ports-implemented = <1>;
> arch/arm64/boot/dts/socionext/uniphier-pxs3.dtsi:                       ports-implemented = <1>;
> 
> 
> Sure, if the ports implemented register was sticky (kept its value after a
> reset), then I think Rob's suggestion would make sense.
> 
> 

Thank you very much for the clarification.

> 
> Kind regards,
> Niklas

Best regards,
Yulin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ