linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] powerpc/pci: Fix endian bug in fixed PHB numbering
@ 2016-08-09  6:55 Michael Ellerman
  2016-08-09 11:26 ` Michael Ellerman
  0 siblings, 1 reply; 2+ messages in thread
From: Michael Ellerman @ 2016-08-09  6:55 UTC (permalink / raw)
  To: linuxppc-dev; +Cc: gpiccoli, gwshan, Benjamin Herrenschmidt

The recent commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number
based on device-tree properties"), added code to read a 64-bit property
from the device tree, and if not found read a 32-bit property (reg).

There was a bug in the 32-bit case, on big endian machines, due to the
use of the 64-bit value to read the 32-bit property. The cast of &prop
means we end up writing to the high 32-bit of prop, leaving the low
32-bits containing whatever junk was on the stack.

If that junk value was non-zero, and < MAX_PHBS, we would end up using
it as the PHB id. This results in users seeing what appear to be random
PHB ids.

Fix it by reading into a u32 property and then assigning that to the
u64 value, letting the CPU do the correct conversions for us.

Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
 arch/powerpc/kernel/pci-common.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a5c0153ede37..7fdf324d5b51 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -78,6 +78,7 @@ EXPORT_SYMBOL(get_pci_dma_ops);
 static int get_phb_number(struct device_node *dn)
 {
 	int ret, phb_id = -1;
+	u32 prop_32;
 	u64 prop;
 
 	/*
@@ -86,8 +87,10 @@ static int get_phb_number(struct device_node *dn)
 	 * reading "ibm,opal-phbid", only present in OPAL environment.
 	 */
 	ret = of_property_read_u64(dn, "ibm,opal-phbid", &prop);
-	if (ret)
-		ret = of_property_read_u32_index(dn, "reg", 1, (u32 *)&prop);
+	if (ret) {
+		ret = of_property_read_u32_index(dn, "reg", 1, &prop_32);
+		prop = prop_32;
+	}
 
 	if (!ret)
 		phb_id = (int)(prop & (MAX_PHBS - 1));
-- 
2.7.4

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: powerpc/pci: Fix endian bug in fixed PHB numbering
  2016-08-09  6:55 [PATCH] powerpc/pci: Fix endian bug in fixed PHB numbering Michael Ellerman
@ 2016-08-09 11:26 ` Michael Ellerman
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Ellerman @ 2016-08-09 11:26 UTC (permalink / raw)
  To: Michael Ellerman, linuxppc-dev; +Cc: gwshan, gpiccoli

On Tue, 2016-09-08 at 06:55:41 UTC, Michael Ellerman wrote:
> The recent commit 63a72284b159 ("powerpc/pci: Assign fixed PHB number
> based on device-tree properties"), added code to read a 64-bit property
> from the device tree, and if not found read a 32-bit property (reg).
> 
> There was a bug in the 32-bit case, on big endian machines, due to the
> use of the 64-bit value to read the 32-bit property. The cast of &prop
> means we end up writing to the high 32-bit of prop, leaving the low
> 32-bits containing whatever junk was on the stack.
> 
> If that junk value was non-zero, and < MAX_PHBS, we would end up using
> it as the PHB id. This results in users seeing what appear to be random
> PHB ids.
> 
> Fix it by reading into a u32 property and then assigning that to the
> u64 value, letting the CPU do the correct conversions for us.
> 
> Fixes: 63a72284b159 ("powerpc/pci: Assign fixed PHB number based on device-tree properties")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

Applied to powerpc fixes.

https://git.kernel.org/powerpc/c/61e8a0d5a0270b91581f6c7150

cheers

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2016-08-09 11:26 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-08-09  6:55 [PATCH] powerpc/pci: Fix endian bug in fixed PHB numbering Michael Ellerman
2016-08-09 11:26 ` Michael Ellerman

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