diff mbox

[v3,4/6] PCI: generic: Correct, and avoid overflow, in bus_max calculation.

Message ID 1442965757-12925-5-git-send-email-ddaney.cavm@gmail.com
State Superseded
Headers show

Commit Message

David Daney Sept. 22, 2015, 11:49 p.m. UTC 
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>
---
No change from v2.
Change from v1: Added text to host-generic-pci.txt

 Documentation/devicetree/bindings/pci/host-generic-pci.txt | 4 +++-
 drivers/pci/host/pci-host-generic.c                        | 7 ++++---
 2 files changed, 7 insertions(+), 4 deletions(-)

Comments

Arnd Bergmann Sept. 23, 2015, 8:01 a.m. UTC | #1 
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
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Daney Sept. 23, 2015, 3:50 p.m. UTC | #2 
On 09/23/2015 01:01 AM, Arnd Bergmann wrote:
> 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.

The pci-host-generic driver only maps the ranges that correspond to the 
"bus-range" buses, so mapping of illegal address ranges should not be a 
problem.

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

I'm not sure if we have the luxury of being able to change the 
definition, although the existing code only works with a starting bus 
number of zero.  From this we might conclude that non-zero starting bus 
numbers cannot exist in the wild, so changing the the definition of 
"reg" so that it starts at the starting bus number might be possible.

My reading of:

http://www.o3one.org/hwdocs/openfirmware/pci_supplement_2_1.pdf

Section 3.1.1, does not preclude your interpretation.  Although that is 
for PCI-PCI bridges, and not this pci-host-generic root complex.

If we really want to go with a different definition of what the "reg" 
property means, then actual code has to change, and we risk breaking 
something.

David Daney


--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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.
 
 
 Properties of the /chosen node:
diff --git a/drivers/pci/host/pci-host-generic.c b/drivers/pci/host/pci-host-generic.c
index 77cf4bd..0a9c453 100644
--- a/drivers/pci/host/pci-host-generic.c
+++ b/drivers/pci/host/pci-host-generic.c
@@ -164,7 +164,7 @@  out_release_res:
 static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
 {
 	int err;
-	u8 bus_max;
+	int bus_max;
 	resource_size_t busn;
 	struct resource *bus_range;
 	struct device *dev = pci->host.dev.parent;
@@ -177,8 +177,9 @@  static int gen_pci_parse_map_cfg_windows(struct gen_pci *pci)
 	}
 
 	/* Limit the bus-range to fit within reg */
-	bus_max = pci->cfg.bus_range->start +
-		  (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
+	bus_max = (resource_size(&pci->cfg.res) >> pci->cfg.ops.bus_shift) - 1;
+	if (bus_max > 255)
+		bus_max = 255;
 	pci->cfg.bus_range->end = min_t(resource_size_t,
 					pci->cfg.bus_range->end, bus_max);