ARMADA espressobin SATA drive detection failure

[Pali Rohár]

On Monday 29 August 2022 00:20:10 Shinichiro Kawasaki wrote:
> On Aug 26, 2022 / 14:05, Marek Behún wrote:
> > On Fri, 26 Aug 2022 05:00:20 +0000
> > Shinichiro Kawasaki <shinichiro.kawasaki at wdc.com> wrote:
> > 
> > > On Aug 26, 2022 / 00:15, Marek Behún wrote:
> > > > On Thu, 25 Aug 2022 15:00:59 +0200
> > > > Pali Rohár <pali at kernel.org> wrote:
> > > >   
> > > > > On Sunday 14 August 2022 01:10:50 Pali Rohár wrote:  
> > > > > > On Saturday 13 August 2022 23:02:34 Shinichiro Kawasaki wrote:  
> > > 
> > > [...]
> > > 
> > > > > > Perfect! So the issue is with mvebu_a3700_comphy_reset() function.
> > > > > > 
> > > > > > This function is not in TF-A code and neither in my original kernel
> > > > > > driver implementation (still available here):
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/commit/?h=phy-mvebu-a3700-comphy&id=4588902a3528195bcfdda9f9e1e14262a1955df1
> > > > > > 
> > > > > > Marek, this function mvebu_a3700_comphy_reset() was implemented by you.
> > > > > > Could you please look at it, why you added this function and try to fix
> > > > > > it? Is this function needed at all?    
> > > > > 
> > > > > PING? Any progress here?  
> > > > 
> > > > Not yet, sorry. Maybe we could do something like I am attaching, until
> > > > I have time to play with it?
> > > > 
> > > > See attached file.  
> > > 
> > > Merek, thanks for the response. I applied the attached patch to v5.18.16 kernel
> > > and observed the "ata1: SATA link down (SStatus 100 SControl 300)" message is
> > > avoided. It looks working.
> > > 
> > 
> > Hello Shinichiro,
> > 
> > would you be able to test another patch I am attaching, on clean kernel?
> > Whether your disk works or not...
> 
> Sure, but unfortunately, it did not work. With "a3720-comphy-test-2.patch",
> still the error "ata1: SATA link down (SStatus 100 SControl 300)" is printed,
> and my SSD is not detected.
> 
> To be precise, this time I switched base kernel from v5.18.16 to v5.19.4, since
> v5.18.y branch reached to EOL. With v5.19.4, my observation is consistent with
> v5.18.16.
> 
> - v5.18.16:
>    without patch: error "ata1: SATA link down (SStatus 100 SControl 300)"
>    with "a3720-comphy-sata.patch": no ata error. my SSD detected
> 
> - v5.19.4:
>    without patch: error "ata1: SATA link down (SStatus 100 SControl 300)"
>    with "a3720-comphy-sata.patch": no ata error. my SSD detected
>    with "a3720-comphy-test-2.patch": error "ata1: SATA link down (SStatus 100 SControl 300)"

Ok, seems that debugging reset callback would take much more time than
we thought. We need working driver in mainline and stable kernels, hence
now I sent a patch (presented earlier) to completely remove PHY reset
support (until we figure out where is the issue).