From: "Pali Rohár" <pali@kernel.org>
To: Marcel Menzel <mail@mcl.gg>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
linux-arm-kernel@lists.infradead.org, linux-pci@vger.kernel.org
Subject: Re: Kernel 5.16.3 and above fails to detect PCIe devices on Turris Omnia (Armada 385 / mvebu)
Date: Fri, 25 Feb 2022 14:27:01 +0100 [thread overview]
Message-ID: <20220225132701.fzqbvynueho2res2@pali> (raw)
In-Reply-To: <3db2e80c-76aa-2f93-7be2-d2c34283289d@mcl.gg>
On Friday 25 February 2022 14:12:30 Marcel Menzel wrote:
> Am 24.02.2022 um 18:21 schrieb Pali Rohár:
> > On Thursday 24 February 2022 10:25:32 Bjorn Helgaas wrote:
> > > On Thu, Feb 24, 2022 at 05:00:30PM +0100, Marcel Menzel wrote:
> > > > +linux-pci
> > > >
> > > > Am 24.02.2022 um 14:52 schrieb Marcel Menzel:
> > > > > Am 24.02.2022 um 14:09 schrieb Marcel Menzel:
> > > > > > Hello,
> > > > > >
> > > > > > When upgrading from kernel 5.16.2 to a newer version (tried 5.16.3
> > > > > > and 5.16.10 with unchanged .config), the Kernel fails to detect both
> > > > > > my installed mPCIe WiFi cards in my Turris Omnia (newer version,
> > > > > > silver case, GPIO pins installed again).
> > > > > > I have two Mediatek MT7915 based cards installed. I also tried with
> > > > > > one Atheros at9k and one ath10k based card, yielding the same
> > > > > > result. On a Kernel version newer than 5.16.2, all cards aren't
> > > > > > getting recognized correctly.
> > > > > >
> > > > > > Before 5.16.3 I also had to disable PCIe ASPM via boot aragument,
> > > > > > otherwise the WiFi drivers would complain about weird device
> > > > > > behaviors and failing to initialize them, but re-enabling it does
> > > > > > not yield any different results.
> > > Please try this commit, which is headed to mainline today:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git/commit/?h=for-linus&id=c49ae619905eebd3f54598a84e4cd2bd58ba8fe9
> > >
> > > This commit should fix the PCI enumeration problem.
> > It should fix that regression. If not, please let me know.
> Can confirm this patch solving the issue. Many thanks!
Perfect!
> > > If you still have
> > > to disable ASPM, that sounds like a separate problem that we should
> > > also try to debug.
> > This is different and known issue and **not** related to ASPM. I spend
> > some time on it, initially I thought it is bug in Atheros cards, but now
> > I'm in impression that this is issue in Marvell PCIe HW that link
> > retraining (required step of ASPM) triggers either Link Down or Hot
> > Reset which triggers another Atheros issue (this one is already
> > documented in kernel pci quirks code).
> >
> > I will try to implement some workaround for this but requirement is to
> > have all new improvements in pci-mvebu.c + pci-aardvark.c drivers... and
> > review process is slow. So it would not be before all those changes are
> > reviewed and merged.
> Removing "pcie_aspm=off" works for my MT7915E based cards, having had no
> issues so far. So it doesn't seem to be an issue with the Marvell hardware
> itself at least.
That is probably because MT7915E card does not trigger that issue. But
I think issue is really in Marvell hardware.
> Regarding Atheros cards: I disabled it back then for my Atheros AR9582 &
> QCA9880 cards and never re-enabled it when I switched to the MT7915E cards,
> which I forgot to mention in my first mail, sorry!
> I put those two cards back into the device to test it, and the same problem
> occurs why I disabled it back then. The router completely freezes while
> booting with this as the last log lines (gathered via serial):
>
> [ 10.400986] ath9k 0000:02:00.0: can't change power state from D3cold to
> D0 (config space inaccessible)
> [ 10.466924] ath10k_pci 0000:03:00.0: can't change power state from D3cold
> to D0 (config space inaccessible)
> [ 10.613847] ath10k_pci 0000:03:00.0: failed to wake up device : -110
At this stage there is no link with the card. But kernel does not know
it as there is missing implementation for DLLSC interrupt in pci-mvebu.c
driver. We need DLLSC support for debugging this issue.
For another Marvell driver (pci-aardvark.c) there is already pending
patch for review which adds DLLSC interrupt support:
https://lore.kernel.org/linux-pci/20220220193346.23789-9-kabel@kernel.org/
So on Armada 3720 platforms it is possible to start debugging it.
I have (experimental) DLLSC support prepared also for pci-mvebu.c but it
depends on summary interrupt which is in missing in irq-armada-370-xp.c:
https://git.kernel.org/pub/scm/linux/kernel/git/pali/linux.git/log/?h=pci-mvebu
So without that summary interrupt in irq-armada-370-xp.c driver it is
not possible to get information about it in pci-mvebu.c driver.
> [ 10.622944] usb 1-1: New USB device found, idVendor=0cf3, idProduct=3004,
> bcdDevice= 0.02
> [ 10.635092] usb 1-1: New USB device strings: Mfr=0, Product=0,
> SerialNumber=0
> [ 10.659930] ath10k_pci: probe of 0000:03:00.0 failed with error -110
>
> This seems to be another topic however. I'd be glad to test and try to debug
> fixes and / or gather additional information on my hardware regarding this
> problem.
prev parent reply other threads:[~2022-02-25 13:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <aa149fc8-c108-5f26-7ae6-5ccc845befd3@mcl.gg>
[not found] ` <a3b5c605-e8ac-1c6d-bbd6-c6fa587535bc@mcl.gg>
2022-02-24 16:00 ` Kernel 5.16.3 and above fails to detect PCIe devices on Turris Omnia (Armada 385 / mvebu) Marcel Menzel
2022-02-24 16:25 ` Bjorn Helgaas
2022-02-24 17:21 ` Pali Rohár
2022-02-25 13:12 ` Marcel Menzel
2022-02-25 13:27 ` Pali Rohár [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220225132701.fzqbvynueho2res2@pali \
--to=pali@kernel.org \
--cc=helgaas@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pci@vger.kernel.org \
--cc=mail@mcl.gg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).