From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: David Daney <ddaney.cavm@gmail.com>,
linux-kernel@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
linux-pci@vger.kernel.org, Will Deacon <will.deacon@arm.com>,
Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
devicetree@vger.kernel.org, Marc Zyngier <marc.zyngier@arm.com>,
David Daney <david.daney@cavium.com>
Subject: Re: [PATCH v3 4/6] PCI: generic: Correct, and avoid overflow, in bus_max calculation.
Date: Wed, 23 Sep 2015 10:01:01 +0200 [thread overview]
Message-ID: <1496061.0ds89jTH75@wuerfel> (raw)
In-Reply-To: <1442965757-12925-5-git-send-email-ddaney.cavm@gmail.com>
On Tuesday 22 September 2015 16:49:15 David Daney wrote:
> From: David Daney <david.daney@cavium.com>
>
> There are two problems with the bus_max calculation:
>
> 1) The u8 data type can overflow for large config space windows.
>
> 2) The calculation is incorrect for a bus range that doesn't start at
> zero.
>
> Since the configuration space is relative to bus zero, make bus_max
> just be the size of the config window scaled by bus_shift. Then clamp
> it to a maximum of 255, per PCI. Use a data type of int to avoid
> overflow problems.
>
> Update host-generic-pci.txt to clarify the semantics of the "reg"
> property with respect to non-zero starting bus numbers.
>
> Signed-off-by: David Daney <david.daney@cavium.com>
Not sure about this one
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index cf3e205..105a968 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -34,7 +34,9 @@ Properties of the host controller node:
> - #size-cells : Must be 2.
>
> - reg : The Configuration Space base address and size, as accessed
> - from the parent bus.
> + from the parent bus. The base address corresponds to
> + bus zero, even though the "bus-range" property may specify
> + a different starting bus number.
This sounds like very unusual behavior. If you have a system with faked
bus numbers where the registers only physically exist for a subset of the
buses, this requires defining a reg property that contains MMIO space
which is outside of the device and potentially contains other devices.
What would break if we instead defined it the expected way and only
list the registers for the bus numbers in the "bus-range" property?
Arnd
next prev parent reply other threads:[~2015-09-23 8:01 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-22 23:49 [PATCH v3 0/6] PCI: generic: Misc. bug fixes/enhancements David Daney
2015-09-22 23:49 ` [PATCH v3 1/6] PCI: Add pci_bus_fixup_irqs() David Daney
2015-09-22 23:49 ` [PATCH v3 2/6] PCI: generic: Only fixup irqs for bus we are creating David Daney
2015-09-22 23:49 ` [PATCH v3 3/6] PCI: generic: Quit clobbering our pci_ops David Daney
2015-09-23 8:21 ` Arnd Bergmann
2015-09-23 15:56 ` David Daney
2015-09-22 23:49 ` [PATCH v3 4/6] PCI: generic: Correct, and avoid overflow, in bus_max calculation David Daney
2015-09-23 8:01 ` Arnd Bergmann [this message]
2015-09-23 15:50 ` David Daney
2015-09-23 19:35 ` Arnd Bergmann
2015-09-22 23:49 ` [PATCH v3 5/6] PCI: generic: Pass proper starting bus number to pci_scan_root_bus() David Daney
2015-09-22 23:49 ` [PATCH v3 6/6] PCI: generic: Claim device resources if PCI_PROBE_ONLY David Daney
2015-09-23 8:02 ` [PATCH v3 0/6] PCI: generic: Misc. bug fixes/enhancements Arnd Bergmann
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=1496061.0ds89jTH75@wuerfel \
--to=arnd@arndb.de \
--cc=bhelgaas@google.com \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mark.rutland@arm.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=will.deacon@arm.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).