[patch] fix RTC/NVRAM accesses on Maple

[patch] fix RTC/NVRAM accesses on Maple

[Hollis Blanchard]

It looks like RTC and NVRAM accesses (including halt/reboot) on Maple
have been broken since January, when an untested build fix went in
("[PATCH] powerpc: Fix Maple build").

PIBS (the firmware on Maple) has a bad "ranges" property for the ISA
bus, which means of_address_to_resource() fails for ISA devices, and
that breaks maple_find_nvram_base() and maple_get_boot_time().

This patch adds ifdefs mid-file, but some were already present anyways,
and I don't see a better way.

Please apply.

-- 
Hollis Blanchard
IBM Linux Technology Center

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

diff -r 5158eb8d85b7 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c	Thu May 18 11:32:22 2006 +0700
+++ b/arch/powerpc/kernel/prom_init.c	Thu May 18 16:23:40 2006 -0500
@@ -2057,10 +2057,44 @@ static void __init flatten_device_tree(v
 
 }
 
-
-static void __init fixup_device_tree(void)
-{
+#ifdef CONFIG_PPC_MAPLE
+/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
+ * The values are bad, and it doesn't even have the right number of cells. */
+static void __init fixup_device_tree_maple(void)
+{
+	phandle isa;
+	u32 isa_ranges[6];
+
+	isa = call_prom("finddevice", 1, 1, ADDR("/ht@0/isa@4"));
+	if (!PHANDLE_VALID(isa))
+		return;
+
+	if (prom_getprop(isa, "ranges", isa_ranges, sizeof(isa_ranges))
+	    == PROM_ERROR)
+		return;
+
+	if (isa_ranges[0] != 0x1 ||
+	    isa_ranges[1] != 0xf4000000 ||
+	    isa_ranges[2] != 0x00010000)
+		return;
+
+	prom_printf("fixing up bogus ISA range on Maple...\n");
+
+	isa_ranges[0] = 0x1;
+	isa_ranges[1] = 0x0;
+	isa_ranges[2] = 0x0;
+	isa_ranges[3] = 0x0;
+	isa_ranges[4] = 0x0;
+	isa_ranges[5] = 0x00010000;
+	prom_setprop(isa, "/ht@0/isa@4", "ranges",
+		     isa_ranges, sizeof(isa_ranges));
+}
+#endif
+
+		
 #if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+static void __init fixup_device_tree_pmac(void)
+{
 	phandle u3, i2c, mpic;
 	u32 u3_rev;
 	u32 interrupts[2];
@@ -2097,9 +2131,18 @@ static void __init fixup_device_tree(voi
 	parent = (u32)mpic;
 	prom_setprop(i2c, "/u3@0,f8000000/i2c@f8001000", "interrupt-parent",
 		     &parent, sizeof(parent));
-#endif
-}
-
+}
+#endif
+
+static void __init fixup_device_tree(void)
+{
+#ifdef CONFIG_PPC_MAPLE
+	fixup_device_tree_maple();
+#endif
+#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+	fixup_device_tree_pmac();
+#endif
+}
 
 static void __init prom_find_boot_cpu(void)
 {

Re: [patch] fix RTC/NVRAM accesses on Maple

[Paul Mackerras]

Hollis Blanchard writes:

> This patch adds ifdefs mid-file, but some were already present anyways,
> and I don't see a better way.

It would look better as:

#ifdef CONFIG_PPC_MAPLE
/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
 * The values are bad, and it doesn't even have the right number of cells. */
static void __init fixup_device_tree_maple(void)
{
	... etc ...
}
#else
#define fixup_device_tree_maple()
#endif

#if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
static void __init fixup_device_tree_pmac(void)
{
	... etc ...
}
#else
#define fixup_device_tree_pmac()
#endif

static void __init fixup_device_tree(void)
{
	fixup_device_tree_maple();
	fixup_device_tree_pmac();
}

Care to redo the patch?

Thanks,
Paul.

Re: [patch] fix RTC/NVRAM accesses on Maple

[Hollis Blanchard]

On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
> 
> It would look better as:
> 
> #ifdef CONFIG_PPC_MAPLE
> /* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
>  * The values are bad, and it doesn't even have the right number of cells. */
> static void __init fixup_device_tree_maple(void)
> {
> 	... etc ...
> }
> #else
> #define fixup_device_tree_maple()
> #endif
> 
> #if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
> static void __init fixup_device_tree_pmac(void)
> {
> 	... etc ...
> }
> #else
> #define fixup_device_tree_pmac()
> #endif
> 
> static void __init fixup_device_tree(void)
> {
> 	fixup_device_tree_maple();
> 	fixup_device_tree_pmac();
> }
> 
> Care to redo the patch?

If you really think that looks better, sure. :)

-Hollis

Re: [patch] fix RTC/NVRAM accesses on Maple

[Hollis Blanchard]

On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
> Care to redo the patch?

After some offline discussion, I think we're in agreement that these
properties are fine, since Linux's device tree code can't handle
multiple ranges. Right Segher?

-- 
Hollis Blanchard
IBM Linux Technology Center

Due to a firmware device tree bug, RTC and NVRAM accesses (including
halt/reboot) on Maple have been broken since January, when an untested
build fix went in. This code patches the device tree in Linux.

Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>

diff -r 5158eb8d85b7 arch/powerpc/kernel/prom_init.c
--- a/arch/powerpc/kernel/prom_init.c	Thu May 18 11:32:22 2006 +0700
+++ b/arch/powerpc/kernel/prom_init.c	Thu May 25 16:30:10 2006 -0500
@@ -2057,10 +2057,45 @@ static void __init flatten_device_tree(v
 
 }
 
-
-static void __init fixup_device_tree(void)
-{
+#ifdef CONFIG_PPC_MAPLE
+/* PIBS Version 1.05.0000 04/26/2005 has an incorrect /ht/isa/ranges property.
+ * The values are bad, and it doesn't even have the right number of cells. */
+static void __init fixup_device_tree_maple(void)
+{
+	phandle isa;
+	u32 isa_ranges[6];
+
+	isa = call_prom("finddevice", 1, 1, ADDR("/ht@0/isa@4"));
+	if (!PHANDLE_VALID(isa))
+		return;
+
+	if (prom_getprop(isa, "ranges", isa_ranges, sizeof(isa_ranges))
+		== PROM_ERROR)
+		return;
+
+	if (isa_ranges[0] != 0x1 ||
+		isa_ranges[1] != 0xf4000000 ||
+		isa_ranges[2] != 0x00010000)
+		return;
+
+	prom_printf("fixing up bogus ISA range on Maple...\n");
+
+	isa_ranges[0] = 0x1;
+	isa_ranges[1] = 0x0;
+	isa_ranges[2] = 0x01002000; /* IO space; PCI device = 4 */
+	isa_ranges[3] = 0x0;
+	isa_ranges[4] = 0x0;
+	isa_ranges[5] = 0x00010000;
+	prom_setprop(isa, "/ht@0/isa@4", "ranges",
+			isa_ranges, sizeof(isa_ranges));
+}
+#else
+#define fixup_device_tree_maple()
+#endif
+
 #if defined(CONFIG_PPC64) && defined(CONFIG_PPC_PMAC)
+static void __init fixup_device_tree_pmac(void)
+{
 	phandle u3, i2c, mpic;
 	u32 u3_rev;
 	u32 interrupts[2];
@@ -2097,9 +2132,16 @@ static void __init fixup_device_tree(voi
 	parent = (u32)mpic;
 	prom_setprop(i2c, "/u3@0,f8000000/i2c@f8001000", "interrupt-parent",
 		     &parent, sizeof(parent));
-#endif
-}
-
+}
+#else
+#define fixup_device_tree_pmac()
+#endif
+
+static void __init fixup_device_tree(void)
+{
+	fixup_device_tree_maple();
+	fixup_device_tree_pmac();
+}
 
 static void __init prom_find_boot_cpu(void)
 {

Re: [patch] fix RTC/NVRAM accesses on Maple

[Segher Boessenkool]

>> Care to redo the patch?
>
> After some offline discussion, I think we're in agreement that these
> properties are fine, since Linux's device tree code can't handle
> multiple ranges. Right Segher?

Not fine, but good enough for now, will need more work elsewhere
before we can do "the right thing" here.

> Hollis Blanchard
> IBM Linux Technology Center
>
> Due to a firmware device tree bug, RTC and NVRAM accesses (including
> halt/reboot) on Maple have been broken since January, when an untested
> build fix went in. This code patches the device tree in Linux.
>
> Signed-off-by: Hollis Blanchard <hollisb@us.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>

Re: [patch] fix RTC/NVRAM accesses on Maple

[jfaslist]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii; format=flowed, Size: 594 bytes --]

Hi,
So the RTC/NVRAM patch is no longer needed for the Maple?
Thanks
-jf simon

Hollis Blanchard wrote:

>On Fri, 2006-05-19 at 08:58 +1000, Paul Mackerras wrote:
>  
>
>>Care to redo the patch?
>>    
>>
>
>After some offline discussion, I think we're in agreement that these
>properties are fine, since Linux's device tree code can't handle
>multiple ranges. Right Segher?
>
>  
>


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [patch] fix RTC/NVRAM accesses on Maple

[Segher Boessenkool]

> So the RTC/NVRAM patch is no longer needed for the Maple?
> Thanks
> -jf simon

[Post-top not do.  Backwards read not do people.]

Hollis' latest patch is needed still.  We agreed not to solve it
completely correctly yet, as we'll need more surgery in other parts
of the PowerPC kernel first.


Segher

Re: [patch] fix RTC/NVRAM accesses on Maple

[jfaslist]

> Hollis' latest patch is needed still.  We agreed not to solve it
> completely correctly yet, as we'll need more surgery in other parts
> of the PowerPC kernel first.
>
> Segher
>
I am trying to apply it on a 2.6.16.18 kernel but the two hunks of it 
are rejected. Any specific version to use?
Thanks,
-jfs


	

	
		
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.
http://fr.mail.yahoo.com

Re: [patch] fix RTC/NVRAM accesses on Maple

[Hollis Blanchard]

[resend from the correct email address]

On Tue, 2006-05-30 at 15:49 +0200, jfaslist wrote:
> > Hollis' latest patch is needed still.  We agreed not to solve it
> > completely correctly yet, as we'll need more surgery in other parts
> > of the PowerPC kernel first.
> I am trying to apply it on a 2.6.16.18 kernel but the two hunks of it 
> are rejected. Any specific version to use?

You could look at the file to see why you're getting rejects. The patch
wasn't committed until 26 May, and 2.6.16.18 was released on 22 May, so
it's more likely you've done something on your side like try to apply
the patch twice (e.g. the original version and then the final version).

-Hollis

Re: [patch] fix RTC/NVRAM accesses on Maple

[Segher Boessenkool]

> +	isa_ranges[0] = 0x1;
> +	isa_ranges[1] = 0x0;
> +	isa_ranges[2] = 0x0;
> +	isa_ranges[3] = 0x0;
> +	isa_ranges[4] = 0x0;
> +	isa_ranges[5] = 0x00010000;
> +	prom_setprop(isa, "/ht@0/isa@4", "ranges",
> +		     isa_ranges, sizeof(isa_ranges));

isa_ranges[2] = 0x01002000;

isa_ranges[5] looks suspicious as well; the value you put in
means that *no* (16-bit, which is all that 8111 supports) legacy
I/O sits on any other than the LPC bus; so no 8111 ATA support,
for example.

Showing only I/O ranges in the "ranges" property means that no
devices below the "isa" node sit on memory space; is that true
for the Maple device tree?  (The node for the flash chip,
specifically, if it exists in their tree at all).  If not, I'll
dig out the proper "ranges" value for it tomorrow (it depends on
hardware settings on their SIO chip, I have no idea what they
set it to right now :-) ).

I'm sure this all works for your kernel right now, but if you're
fixing up, let's fix it properly :-)


Segher