From: Niklas Cassel <cassel@kernel.org>
To: luyulin@eswincomputing.com
Cc: Rob Herring <robh@kernel.org>,
dlemoal@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
linux-ide@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, vkoul@kernel.org,
kishon@kernel.org, linux-phy@lists.infradead.org,
ningyu@eswincomputing.com, zhengyu@eswincomputing.com,
linmin@eswincomputing.com, huangyifeng@eswincomputing.com,
fenglin@eswincomputing.com, lianghujun@eswincomputing.com
Subject: Re: Re: [PATCH v2 1/3] dt-bindings: ata: eswin: Document for EIC7700 SoC ahci
Date: Thu, 28 Aug 2025 15:05:15 +0200 [thread overview]
Message-ID: <aLBUC116MdJqDGIJ@flawful.org> (raw)
In-Reply-To: <692e11ca.843.198f0337528.Coremail.luyulin@eswincomputing.com>
On Thu, Aug 28, 2025 at 06:22:40PM +0800, luyulin@eswincomputing.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
next prev parent reply other threads:[~2025-08-28 13:05 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 13:47 [PATCH v2 0/3] ESWIN EIC7700 sata phy driver and yaml, Yulin Lu
2025-08-19 13:54 ` [PATCH v2 1/3] dt-bindings: ata: eswin: Document for EIC7700 SoC ahci Yulin Lu
2025-08-19 14:25 ` Rob Herring
2025-08-25 8:19 ` luyulin
2025-08-28 10:22 ` luyulin
2025-08-28 13:05 ` Niklas Cassel [this message]
2025-08-29 6:22 ` luyulin
2025-08-19 14:00 ` [PATCH v2 3/3] phy: eswin: Create eswin directory and add EIC7700 SATA PHY driver Yulin Lu
2025-08-20 16:07 ` Vinod Koul
2025-08-21 8:41 ` kernel test robot
2025-08-20 9:27 ` [PATCH v2 2/3] dt-bindings: phy: eswin: Document for EIC7700 SoC SATA PHY Yulin Lu
2025-08-21 7:55 ` Krzysztof Kozlowski
2025-08-26 3:23 ` luyulin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aLBUC116MdJqDGIJ@flawful.org \
--to=cassel@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dlemoal@kernel.org \
--cc=fenglin@eswincomputing.com \
--cc=huangyifeng@eswincomputing.com \
--cc=kishon@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=lianghujun@eswincomputing.com \
--cc=linmin@eswincomputing.com \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=luyulin@eswincomputing.com \
--cc=ningyu@eswincomputing.com \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
--cc=zhengyu@eswincomputing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).