On Thu Apr 17, 2025 at 6:20 PM CEST, Dragan Simic wrote:
On 2025-04-17 16:21, Diederik de Haas wrote:
The documentation for the phy_power_off() function explicitly says
Must be called before phy_exit().
So let's follow that instruction.
Fixes: 0e898eb8df4e ("PCI: rockchip-dwc: Add Rockchip RK356X host
controller driver")
Cc: stable@xxxxxxxxxxxxxxx # v5.15+
Signed-off-by: Diederik de Haas <didi.debian@xxxxxxxxx>
---
drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
index c624b7ebd118..4f92639650e3 100644
--- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c
+++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c
@@ -410,8 +410,8 @@ static int rockchip_pcie_phy_init(struct
rockchip_pcie *rockchip)
static void rockchip_pcie_phy_deinit(struct rockchip_pcie *rockchip)
{
- phy_exit(rockchip->phy);
phy_power_off(rockchip->phy);
+ phy_exit(rockchip->phy);
}
static const struct dw_pcie_ops dw_pcie_ops = {
Thanks for the patch, it's looking good to me. The current state
of the rockchip_pcie_phy_deinit() function might actually not cause
issues because the rockchip_pcie_phy_deinit() function is used only
in the error-handling path in the rockchip_pcie_probe() function,
so having no runtime errors leads to no possible issues.
However, it doesn't mean it shouldn't be fixed, and it would actually
be good to dissolve the rockchip_pcie_phy_deinit() function into the
above-mentioned error-handling path. It's a short, two-line function
local to the compile unit, used in a single place only, so dissolving
it is safe and would actually improve the readability of the code.
This patch came about while looking at [1] "PCI: dw-rockchip: Add system
PM support", which would be the 2nd consumer of the
rockchip_pcie_phy_deinit() function. That patch's commit message has the
following: "tries to reuse possible exist(ing) code"
Being a fan of the DRY principle, that sounds like an excellent idea :-)
So while you're right if there would only be 1 consumer, which is the
case *right now*, given that a 2nd consumer is in the works, I think
it's better to keep it as I've done it now.
Let me know if you disagree (including why).
[1] https://lore.kernel.org/linux-rockchip/1744352048-178994-1-git-send-email-shawn.lin@xxxxxxxxxxxxxx/