Re: ARMADA espressobin SATA drive detection failure
From: Pali Rohár <pali@kernel.org>
Date: 2022-08-13 09:32:24
On Saturday 13 August 2022 01:35:35 Shinichiro Kawasaki wrote:
On Aug 13, 2022 / 03:03, Pali Rohár wrote:quoted
On Saturday 13 August 2022 01:00:34 Shinichiro Kawasaki wrote:quoted
On Aug 13, 2022 / 02:15, Pali Rohár wrote:quoted
On Saturday 13 August 2022 00:02:37 Shinichiro Kawasaki wrote:quoted
On Aug 12, 2022 / 15:55, Pali Rohár wrote:quoted
On Friday 12 August 2022 14:44:07 Pali Rohár wrote:[...]quoted
quoted
Probably this is SSD disk specific. I will try to prepare some kernel changes to test if it changes something.Could you please try following change and provide full dmesg log? First I need to know if issue is in SATA power on code or somewhere else.My pleasure. I applied the patch to the kernel v5.18.16 and booted it from the latest U-Boot. Here I attach console output taken from the mox-imager command. It has all kernel messages as well as U-Boot console log. I find the message from added dev_err(): mvebu-a3700-comphy d0018300.phy: OK mvebu_a3700_comphy_sata_power_on() call -- Shin'ichiro KawasakiOk, so SATA does not work even when starting with original SMC implementation. Could you please try another test change?@@ -1102,6 +1142,9 @@ static int mvebu_a3700_comphy_reset(struct phy *phy) struct mvebu_a3700_comphy_lane *lane = phy_get_drvdata(phy); u16 mask, data; + dev_err(lane->dev, "IGNORING mvebu_a3700_comphy_reset() call\n"); + return; + dev_dbg(lane->dev, "resetting lane %d\n", lane->id); /* COMPHY reset for internal logic */Yes, I've applied the hunk above on top of the previous debug patch (I modified 'return' to 'return 0' to avoid a compile error). I attach the console log.Ou, right.quoted
With this change, - The added message "IGNORING mvebu_a3700_comphy_reset() call" was printed three times. - The "ata1: SATA link down (SStatus 100 SControl 300)" message disappeared. - My SSD was detected as /dev/sda.Perfect! Could you now test only that last small change for mvebu_a3700_comphy_reset() without previous changes? To verify that issue is in mvebu_a3700_comphy_reset() function.Sure, I've tried the mvebu_a3700_comphy_reset() change only and got same result: "IGNORING mvebu_a3700_comphy_reset() call" was printed, and my SSD was detected as /dev/sda. FYI, I attach the console log again.
Ok, thanks for testing. It looks like that reset code has some issues. Could you please test this change?
@@ -1393,7 +1436,8 @@ static int mvebu_a3700_comphy_probe(struct platform_device *pdev) * To avoid relying on the bootloader/firmware configuration, * power off all comphys. */ - mvebu_a3700_comphy_reset(phy); +// mvebu_a3700_comphy_reset(phy); + mvebu_a3700_comphy_power_off(phy); lane->needs_reset = false; }
It should replace reset code by power off at beginning / probe time. -- linux-phy mailing list linux-phy@lists.infradead.org https://lists.infradead.org/mailman/listinfo/linux-phy