From: Bjorn Helgaas <helgaas@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
linux-pci@vger.kernel.org, "Jan Palus" <jpalus@fastmail.com>,
"Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Marek Behún" <kabel@kernel.org>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>
Subject: Re: [Bug 215540] New: mvebu: no pcie devices detected on turris omnia (5.16.3 regression)
Date: Thu, 3 Feb 2022 09:47:28 -0600 [thread overview]
Message-ID: <20220203154728.GA96160@bhelgaas> (raw)
In-Reply-To: <20220203125528.s5ct2mtwyil2ggmj@pali>
[+cc Lorenzo, beginning of thread:
https://lore.kernel.org/r/20220127234917.GA150851@bhelgaas]
On Thu, Feb 03, 2022 at 01:55:28PM +0100, Pali Rohár wrote:
> On Thursday 03 February 2022 13:26:42 Pali Rohár wrote:
> > On Thursday 27 January 2022 17:49:17 Bjorn Helgaas wrote:
> > > On Thu, Jan 27, 2022 at 10:52:43PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=215540
> > > >
> > > > Bug ID: 215540
> > > > Summary: mvebu: no pcie devices detected on turris omnia
> > > > (5.16.3 regression)
> > > > Product: Drivers
> > > > Version: 2.5
> > > > Kernel Version: 5.16.3
> > > > Hardware: ARM
> > > > OS: Linux
> > > > Tree: Mainline
> > > > Status: NEW
> > > > Severity: normal
> > > > Priority: P1
> > > > Component: PCI
> > > > Assignee: drivers_pci@kernel-bugs.osdl.org
> > > > Reporter: jpalus@fastmail.com
> > > > Regression: No
> > > >
> > > > After kernel upgrade from 5.16.1 to 5.16.3 Turris Omnia (Armada 385)
> > > > no longer detects pcie devices (wifi/msata). Haven't tried 5.16.2
> > > > but it doesn't seem to have any relevant changes, while 5.16.3
> > > > carries a few.
>
> I found another issue: Into stable tree was backported "modified" patch.
> I'm not sure it is is source of this issue but looks like it is related.
>
> If you open mentioned problematic commit in web ui:
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=7cde9bf0731688896831f90da9fe755f44a6d5e0
>
> And compare it with patch which is on "Link:" line from commit message:
> https://lore.kernel.org/r/20211125124605.25915-12-pali@kernel.org
>
> You will see that diffs are different. In my original patch (which I
> sent to ML) is:
>
> mvebu_pcie_setup_hw(port);
> mvebu_pcie_set_local_dev_nr(port, 1);
> + mvebu_pcie_set_local_bus_nr(port, 0);
>
> But in git web ui is:
>
> mvebu_pcie_setup_hw(port);
> - mvebu_pcie_set_local_dev_nr(port, 1);
> + mvebu_pcie_set_local_dev_nr(port, 0);
>
> I do not know how it could happen. But local **device** number must be
> always set to 1 (see comment above code for explanation) and default
> value of local **bus** number should be 0 (as is in my original patch).
>
> So above patch in stable tree is broken.
I think current mainline is broken, too, isn't it? See below.
> Bjorn & Greg: How do you want to handle this situation? Should I prepare
> special patch for stable which fix it? Or something else?
>
> Anyway, do you know how it could happen that patch was incorrectly
> auto-backported into stable? Differences between original and
> wrongly-modified patch looks very similar (both "bus" and "dev" keywords
> have same number of characters) and it was hard for me to see that there
> are differences. So probably overlooking could happen or maybe git or
> patch tools could do such small changes when doing backports?
Your patch on the mailing list [1] contains:
mvebu_pcie_setup_hw(port);
mvebu_pcie_set_local_dev_nr(port, 1);
+ mvebu_pcie_set_local_bus_nr(port, 0);
91a8d79fc797 ("PCI: mvebu: Fix configuring secondary bus of PCIe Root
Port via emulated bridge") [2] appeared in v5.17-rc1 and contains:
mvebu_pcie_setup_hw(port);
- mvebu_pcie_set_local_dev_nr(port, 1);
+ mvebu_pcie_set_local_dev_nr(port, 0);
And this is the current state of mainline [3].
91a8d79fc797 was backported to v5.16.3 as 7cde9bf07316 [4], which also
contains:
mvebu_pcie_setup_hw(port);
- mvebu_pcie_set_local_dev_nr(port, 1);
+ mvebu_pcie_set_local_dev_nr(port, 0);
So I think the problem was a merge error when we first applied this
for mainline, and we just need to make a patch for mainline, apply it
for v5.17, and mark it for stable.
Bjorn
[1] https://lore.kernel.org/r/20211125124605.25915-12-pali@kernel.org
[2] https://git.kernel.org/linus/91a8d79fc797
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pci-mvebu.c?id=v5.17-rc2#n1323
[4] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.16.y&id=7cde9bf07316
next prev parent reply other threads:[~2022-02-03 15:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <bug-215540-41252@https.bugzilla.kernel.org/>
2022-01-27 23:49 ` [Bug 215540] New: mvebu: no pcie devices detected on turris omnia (5.16.3 regression) Bjorn Helgaas
2022-01-28 5:08 ` Thorsten Leemhuis
2022-02-03 12:26 ` Pali Rohár
2022-02-03 12:54 ` Jan Palus
2022-02-03 12:55 ` Pali Rohár
2022-02-03 13:15 ` Jan Palus
2022-02-03 15:47 ` Bjorn Helgaas [this message]
2022-02-11 19:43 ` Pali Rohár
2022-02-11 19:57 ` Bjorn Helgaas
2022-02-14 12:54 ` 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=20220203154728.GA96160@bhelgaas \
--to=helgaas@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jpalus@fastmail.com \
--cc=kabel@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=pali@kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/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