linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Pali Rohár" <pali@kernel.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Marcel Menzel <mail@mcl.gg>,
	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: Thu, 24 Feb 2022 18:21:36 +0100	[thread overview]
Message-ID: <20220224172136.ydx4wu7avmfq4ndt@pali> (raw)
In-Reply-To: <20220224162532.GA274119@bhelgaas>

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.

> 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.

  reply	other threads:[~2022-02-24 17:21 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 [this message]
2022-02-25 13:12         ` Marcel Menzel
2022-02-25 13:27           ` Pali Rohár

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=20220224172136.ydx4wu7avmfq4ndt@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).