From: Bjorn Helgaas <helgaas@kernel.org>
To: "Pali Rohár" <pali@kernel.org>
Cc: "Thomas Petazzoni" <thomas.petazzoni@bootlin.com>,
"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Marek Behún" <kabel@kernel.org>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 08/15] PCI: mvebu: Propagate errors when updating PCI_IO_BASE and PCI_MEM_BASE registers
Date: Thu, 20 Jan 2022 13:37:13 -0600 [thread overview]
Message-ID: <20220120193713.GA1060589@bhelgaas> (raw)
In-Reply-To: <20220120190826.wkhkcx53lmafq2yp@pali>
On Thu, Jan 20, 2022 at 08:08:26PM +0100, Pali Rohár wrote:
> On Thursday 20 January 2022 11:50:47 Bjorn Helgaas wrote:
> > On Thu, Jan 13, 2022 at 11:35:23AM +0100, Pali Rohár wrote:
> > > On Wednesday 12 January 2022 18:19:21 Bjorn Helgaas wrote:
> > > > On Sat, Jan 08, 2022 at 12:46:58AM +0100, Pali Rohár wrote:
> > > > > On Friday 07 January 2022 17:16:17 Bjorn Helgaas wrote:
> > > > > > On Fri, Jan 07, 2022 at 11:28:26PM +0100, Pali Rohár wrote:
> > > > > > > On Friday 07 January 2022 15:55:04 Bjorn Helgaas wrote:
> > > > > > > > On Thu, Nov 25, 2021 at 01:45:58PM +0100, Pali Rohár wrote:
> > > > > > > > > Properly propagate failure from
> > > > > > > > > mvebu_pcie_add_windows() function back to the caller
> > > > > > > > > mvebu_pci_bridge_emul_base_conf_write() and
> > > > > > > > > correctly updates PCI_IO_BASE, PCI_MEM_BASE and
> > > > > > > > > PCI_IO_BASE_UPPER16 registers on error. On error
> > > > > > > > > set base value higher than limit value which
> > > > > > > > > indicates that address range is disabled.
> > Regardless, this means PCI thinks [mem 0xe0000000-0xe7ffffff] is
> > available on bus 00 and can be assigned to devices on bus 00
> > according to the normal PCI rules (BARs aligned on size, PCI
> > bridge windows aligned on 1MB and multiple of 1MB in size). IIUC,
> > mvebu imposes additional alignment constraints on the bridge
> > windows.
> >
> > These are the bridge window assignments from your dmesg:
> >
> > > pci 0000:00:01.0: BAR 8: assigned [mem 0xe0000000-0xe00fffff]
> > > pci 0000:00:02.0: BAR 8: assigned [mem 0xe0200000-0xe04fffff]
> > > pci 0000:00:03.0: BAR 8: assigned [mem 0xe0100000-0xe01fffff]
> >
> > > pci 0000:00:01.0: PCI bridge to [bus 01]
> > > pci 0000:00:01.0: bridge window [mem 0xe0000000-0xe00fffff]
> > > pci 0000:00:02.0: PCI bridge to [bus 02]
> > > pci 0000:00:02.0: bridge window [mem 0xe0200000-0xe04fffff]
> > > pci 0000:00:03.0: PCI bridge to [bus 03]
> > > pci 0000:00:03.0: bridge window [mem 0xe0100000-0xe01fffff]
> >
> > The PCI core knows nothing about the mvebu constraints. Are we
> > just lucky here that when PCI assigned these bridge windows, they
> > happen to be supported on mvebu? What happens if PCI decides it
> > needs 29MB on bus 01?
>
> In this case pci-mvebu.c split 29MB window into continuous ranges of
> power of two (16MB + 8MB + 4MB + 1MB) and then register each range
> to mbus slot. Code is in function mvebu_pcie_add_windows():
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/pci/controller/pci-mvebu.c?h=v5.15#n300
>
> So at the end there is continuous space of 29MB PCIe window, just it
> "eats" 4 mbus slots.
>
> This function may fail (if there is not enough free mbus slots) and
> this patch is propagating that failure back to the caller.
This failure cannot occur in conforming PCI hardware. I guess if you
want to propagate the error from mvebu_pcie_add_windows() back to
mvebu_pci_bridge_emul_base_conf_write() and do something there, I'm OK
with that.
But change the commit log so it doesn't say "... and correctly update
PCI_IO_BASE, PCI_MEM_BASE and PCI_IO_BASE_UPPER16" because this is
completely device-specific behavior and is not "correct" per any PCI
spec.
Instead, say something about how mvebu doesn't support arbitrary
windows and we're disabling the window completely if we can't provide
what's requested.
Maybe this error warrants a clue in dmesg? How would a user figure
out what's going on in this situation? From the patch, it looks like
we would assign resources to a device, but the device just would not
work because the root port window was silently disabled?
Bjorn
next prev parent reply other threads:[~2022-01-20 19:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-25 12:45 [PATCH 00/15] pci: mvebu: Various fixes Pali Rohár
2021-11-25 12:45 ` [PATCH 01/15] PCI: mvebu: Check for valid ports Pali Rohár
2021-11-25 12:45 ` [PATCH 02/15] PCI: mvebu: Check for errors from pci_bridge_emul_init() call Pali Rohár
2021-11-25 12:45 ` [PATCH 03/15] PCI: mvebu: Check that PCI bridge specified in DT has function number zero Pali Rohár
2022-01-07 18:15 ` Bjorn Helgaas
2022-01-07 18:18 ` Pali Rohár
2022-01-07 21:09 ` Bjorn Helgaas
2022-01-07 21:58 ` Pali Rohár
2021-11-25 12:45 ` [PATCH 04/15] PCI: mvebu: Handle invalid size of read config request Pali Rohár
2022-01-07 18:45 ` Bjorn Helgaas
2022-01-07 19:15 ` Russell King (Oracle)
2021-11-25 12:45 ` [PATCH 05/15] PCI: mvebu: Disallow mapping interrupts on emulated bridges Pali Rohár
2022-01-07 21:32 ` Bjorn Helgaas
2022-01-07 22:13 ` Pali Rohár
2022-01-07 23:01 ` Bjorn Helgaas
2022-01-07 23:11 ` Pali Rohár
2021-11-25 12:45 ` [PATCH 06/15] PCI: mvebu: Fix support for bus mastering and PCI_COMMAND on emulated bridge Pali Rohár
2021-11-25 12:45 ` [PATCH 07/15] PCI: mvebu: Do not modify PCI IO type bits in conf_write Pali Rohár
2021-11-25 12:45 ` [PATCH 08/15] PCI: mvebu: Propagate errors when updating PCI_IO_BASE and PCI_MEM_BASE registers Pali Rohár
2022-01-07 21:55 ` Bjorn Helgaas
2022-01-07 22:28 ` Pali Rohár
2022-01-07 23:16 ` Bjorn Helgaas
2022-01-07 23:46 ` Pali Rohár
2022-01-13 0:19 ` Bjorn Helgaas
2022-01-13 10:35 ` Pali Rohár
2022-01-20 17:50 ` Bjorn Helgaas
2022-01-20 19:08 ` Pali Rohár
2022-01-20 19:37 ` Bjorn Helgaas [this message]
2021-11-25 12:45 ` [PATCH 09/15] PCI: mvebu: Setup PCIe controller to Root Complex mode Pali Rohár
2021-11-25 12:46 ` [PATCH 10/15] PCI: mvebu: Set PCI Bridge Class Code to PCI Bridge Pali Rohár
2021-11-25 12:46 ` [PATCH 11/15] PCI: mvebu: Fix configuring secondary bus of PCIe Root Port via emulated bridge Pali Rohár
2021-11-25 12:46 ` [PATCH 12/15] PCI: mvebu: Fix support for PCI_BRIDGE_CTL_BUS_RESET on " Pali Rohár
2021-11-25 12:46 ` [PATCH 13/15] PCI: mvebu: Fix support for PCI_EXP_DEVCTL " Pali Rohár
2021-11-25 12:46 ` [PATCH 14/15] PCI: mvebu: Fix support for PCI_EXP_RTSTA " Pali Rohár
2021-11-25 12:46 ` [PATCH 15/15] PCI: mvebu: Fix support for DEVCAP2, DEVCTL2 and LNKCTL2 registers " Pali Rohár
2022-01-04 15:04 ` [PATCH 00/15] pci: mvebu: Various fixes Lorenzo Pieralisi
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=20220120193713.GA1060589@bhelgaas \
--to=helgaas@kernel.org \
--cc=bhelgaas@google.com \
--cc=kabel@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=pali@kernel.org \
--cc=robh@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;
as well as URLs for NNTP newsgroup(s).