[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLBUC116MdJqDGIJ@flawful.org>
Date: Thu, 28 Aug 2025 15:05:15 +0200
From: Niklas Cassel <cassel@...nel.org>
To: luyulin@...incomputing.com
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: [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.
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.
Kind regards,
Niklas
Powered by blists - more mailing lists