[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221014133809.y7wvbxx2cvmsjoo7@mobilestation>
Date: Fri, 14 Oct 2022 16:38:09 +0300
From: Serge Semin <Sergey.Semin@...kalelectronics.ru>
To: Arnd Bergmann <arnd@...db.de>
CC: Serge Semin <fancer.lancer@...il.com>,
Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
Anders Roxell <anders.roxell@...aro.org>,
Naresh Kamboju <naresh.kamboju@...aro.org>,
open list <linux-kernel@...r.kernel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
<regressions@...ts.linux.dev>,
"open list:LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)"
<linux-ide@...r.kernel.org>, <lkft-triage@...ts.linaro.org>,
Lukas Bulwahn <lukas.bulwahn@...il.com>,
Niklas Cassel <niklas.cassel@....com>
Subject: Re: TI: X15 the connected SSD is not detected on Linux next 20221006
tag
On Fri, Oct 14, 2022 at 09:31:55AM +0200, Arnd Bergmann wrote:
> On Fri, Oct 14, 2022, at 2:22 AM, 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 ?
>
> The x15 uses "snps,dwc-ahci". I would expect it to detect the device
> with the new driver if that is loaded, but it's possible that the
> driver does not work on all versions of the dwc-ahci hardware.
>
> Anders, can you provide the boot log from a boot with the new driver
> built in? There should be some messages from dwc-ahci about finding
> the device, but then not ultimately working.
>
Yes. The boot-log would be very useful.
> Depending on which way it goes wrong, the safest fallback for 6.1 is
> probably to move the "snps,spear-ahci" and "snps,dwc-ahci" compatible
> strings back into the old driver, and leave the new one only for
> the "baikal,bt1-ahci" implementation of it, until it has been
> successfully verified on TI am5/dra7, spear13xx and exynos.
Right. This would be a possible solution. But I'd rather suggest to at
least try to debug the problem.
-Sergey
>
> Arnd
>
Powered by blists - more mailing lists