Re: TI: X15 the connected SSD is not detected on Linux next 20221006 tag

[Serge Semin]

Hello Damien, Anders

On Fri, Oct 14, 2022 at 09:22:34AM +0900, Damien Le Moal wrote:
> On 10/14/22 07:07, Anders Roxell wrote:
> [...]
> >> 8)
> >>> If reverting these patches restores the eSATA port on this board, then you need
> >>> to fix the defconfig for that board.
> >>
> >> OTOH,
> >> Anders, enabled the new config CONFIG_AHCI_DWC=y  and tried but the
> >> device failed to boot.
> > 
> > I thought it would work with enabling CONFIG_AHCI_DWC=y, but it didn't...
> 
> As mentioned in my previous reply to Naresh, this is a new driver added in
> 6.1. Your board was working before so this should not be the driver needed
> for it.
> 
> > However, reverting patch 33629d35090f ("ata: ahci: Add DWC AHCI SATA
> > controller support")
> > from next-20221013 was a success, kernel booted  and the 'mkfs.ext4' cmd was
> > successful.
> 
> Which is very strange... There is only one hunk in that commit that could
> be considered suspicious:
> 
> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
> index 9b56490ecbc3..8f5572a9f8f1 100644
> --- a/drivers/ata/ahci_platform.c
> +++ b/drivers/ata/ahci_platform.c
> @@ -80,9 +80,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_platform_suspend,
>  static const struct of_device_id ahci_of_match[] = {
>         { .compatible = "generic-ahci", },
>         /* Keep the following compatibles for device tree compatibility */
> -       { .compatible = "snps,spear-ahci", },
>         { .compatible = "ibm,476gtr-ahci", },
> -       { .compatible = "snps,dwc-ahci", },
>         { .compatible = "hisilicon,hisi-ahci", },
>         { .compatible = "cavium,octeon-7130-ahci", },
>         { /* sentinel */ }
> 

> Is your board using one of these compatible string ?

No. My board isn't using them. As a quick-fix they could be got back
to the generic driver. But please see below.

> 
> Serge ?
> Any idea ?

The only difference between ahci_platform.c and ahci_dwc.c relevant to
these compatibles is in calling the next methods:
 ahci_dwc_check_cap(hpriv);
 ahci_dwc_init_timer(hpriv);
 ahci_dwc_init_dmacr(hpriv);
As a first step on debugging the problem I would comment them out and
try to boot the system with the snps,dwc-ahci device being probed by
the ahci_dwc.c driver.

Let's try to test that out first. Then we can narrow down the scale
by commenting out one of these methods and then up to some parts of
it. What do you think?

-Sergey

> 
> -- 
> Damien Le Moal
> Western Digital Research
> 
>