* Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
From: Christoph Hellwig @ 2006-10-17 13:22 UTC (permalink / raw)
To: Nicolas DET; +Cc: akpm, linuxppc-dev, Sven Luther, tilmann
In-Reply-To: <4534BE9D.7030908@bplan-gmbh.de>
> --- a/arch/powerpc/kernel/rtas-proc.c 2006-10-14 05:34:03.000000000 +0200
> +++ b/arch/powerpc/kernel/rtas-proc.c 2006-10-16 10:46:16.000000000 +0200
> @@ -253,43 +253,70 @@ static void get_location_code(struct seq
> static void check_location_string(struct seq_file *m, char *c);
> static void check_location(struct seq_file *m, char *c);
>
> +#ifdef CONFIG_PPC64
> +#define PROCRTAS_ROOT "ppc64"
> +#else
> +#define PROCRTAS_ROOT "ppc"
Please don't do any pathname changes. Even if ppc64 isn't correct it's
what applications expect and what we should provide for a coherent user
interface.
> - if (!machine_is(pseries))
> + if ( ! ( machine_is(pseries) || machine_is(chrp) ) )
> return -ENODEV;
This should be the only change you need, and it should follow kernel
coding style, aka:
if (!machine_is(pseries) && !machine_is(chrp))
return -ENODEV;
> rtas_node = of_find_node_by_name(NULL, "rtas");
> if (rtas_node == NULL)
> return -ENODEV;
And given this check I wonder why we need the platform check at all. It
should be safe to just remove it.
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Andrey Volkov @ 2006-10-17 13:54 UTC (permalink / raw)
To: dedekind; +Cc: Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <1161092193.3260.61.camel@sauron>
Artem Bityutskiy wrote:
> On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
>> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
>> how about to fix scan.c?
>
> Andrey,
>
> I am not JFFS2 maintainer, David Woodhouse is.
Ok, I'll keep it in mind.
>
> Just looked into your patch. I agree that it may make sense to teach
> JFFS2 to use only aligned addresses, but your patch changes
> include/asm-ppc/io.h which is probably not MTD's business.
> It probably
> makes sense to submit these changes to a PPC maintainer separately.
>
> A question - does this mean that one can write only 4-byte chunks to
> this NOR (?) flash?
>
No, MPC5200 could write any size chunks, but it must be aligned (same
restrictions as in SH4), and this restriction applied only to LPB, but
not SDRAM.
Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
functions which MTD drivers exported, but jffs2_scan_dirent_node and
friends - doesn't.
Andrey
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Artem Bityutskiy @ 2006-10-17 13:36 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <4534D8A5.7060206@varma-el.com>
On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?
Andrey,
I am not JFFS2 maintainer, David Woodhouse is.
Just looked into your patch. I agree that it may make sense to teach
JFFS2 to use only aligned addresses, but your patch changes
include/asm-ppc/io.h which is probably not MTD's business. It probably
makes sense to submit these changes to a PPC maintainer separately.
A question - does this mean that one can write only 4-byte chunks to
this NOR (?) flash?
--=20
Best regards,
Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90=
=D1=80=D1=82=D1=91=D0=BC)
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Artem Bityutskiy @ 2006-10-17 14:18 UTC (permalink / raw)
To: Andrey Volkov; +Cc: Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <4534D8A5.7060206@varma-el.com>
On Tue, 2006-10-17 at 17:20 +0400, Andrey Volkov wrote:
> Andrea, check ml archive, I already sent patch half-year ago
> (http://ozlabs.org/pipermail/linuxppc-embedded/2006-April/022566.html)
> Problem is in alignment/memcpy: JFFS2 code assumed that memory at
> unaligned addresses could be touched, but access to an external MMIO
> on MPC5200 _must_ be aligned (i.e. you could not read u32 from odd addres=
s).
>=20
> P.S. Artem, I repeat, I sent this patch _HALF_YEAR_AGO_
> how about to fix scan.c?
Just talked to David. Please, find the result of our discussion in my
edition below.
Strictly speaking, JFFS2 *does not* do anything wrong, so it should not
be fixed. Indeed, JFFS2 does have full right to use memcpy() for that.
The question is: does memcpy() make sense for flash adresses at your
board? Is it a valid operation for flash addresses at your board?
If the answer is yes - then please fix memcpy() for your platform.
If no - then please, do not pretend that your flash may be treated as
memory and fix your platform MTD driver. Namely, set point()/unpoint()
to NULL in your mapping driver - JFFS2 should work then.
--=20
Best regards,
Artem Bityutskiy (=D0=91=D0=B8=D1=82=D1=8E=D1=86=D0=BA=D0=B8=D0=B9 =D0=90=
=D1=80=D1=82=D1=91=D0=BC)
^ permalink raw reply
* Re: [PATCH] Slight refactor of interrupt mapping for FSL parts
From: Kumar Gala @ 2006-10-17 15:50 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev, Jeff Garzik
In-Reply-To: <Pine.LNX.4.61.0610170125160.10940@ld0175-tx32.am.freescale.net>
On Oct 17, 2006, at 1:27 AM, Andy Fleming wrote:
> * Cleaned up interrupt mapping a little by adding a helper
> function which parses the irq out of the device-tree, and puts
> it into a resource.
> * Changed the PHY Layer to use NO_IRQ instead of -1 for PHY_POLL.
> This means that polling will always be used if mapping the
> interrupt fails for any reason.
> * Changed the arch/ppc platform files to specify PHY_POLL, instead
> of -1
> * Changed the fixed phy to use PHY_IGNORE_INTERRUPT
> ---
> This is a respin of the patch to reply to comments from the community
>
> arch/powerpc/sysdev/fsl_soc.c | 27 +++++++++
> +----------------
> arch/ppc/platforms/85xx/mpc8540_ads.c | 4 ++--
> arch/ppc/platforms/85xx/mpc8560_ads.c | 4 ++--
> arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 6 +++---
> arch/ppc/platforms/85xx/sbc8560.c | 2 +-
> arch/ppc/platforms/85xx/stx_gp3.c | 2 +-
> arch/ppc/platforms/85xx/tqm85xx.c | 4 ++--
> drivers/net/phy/fixed.c | 2 +-
> include/asm-powerpc/prom.h | 7 +++++++
> include/linux/phy.h | 7 ++++++-
> 10 files changed, 35 insertions(+), 30 deletions(-)
What about arch/ppc/platforms/83xx? also arch/ppc/platforms/
mpc8272ads_setup.c
[snip]
> diff --git a/include/linux/phy.h b/include/linux/phy.h
> index 9447a57..4dbffe4 100644
> --- a/include/linux/phy.h
> +++ b/include/linux/phy.h
> @@ -20,6 +20,7 @@ #define __PHY_H
>
> #include <linux/spinlock.h>
> #include <linux/device.h>
> +#include <asm/irq.h>
>
> #define PHY_BASIC_FEATURES (SUPPORTED_10baseT_Half | \
> SUPPORTED_10baseT_Full | \
> @@ -37,7 +38,11 @@ #define PHY_GBIT_FEATURES (PHY_BASIC_FEA
> * or not desired for this PHY. Set to PHY_IGNORE_INTERRUPT if
> * the attached driver handles the interrupt
> */
> -#define PHY_POLL -1
> +#ifndef NO_IRQ
> +#define NO_IRQ 0
> +#endif
> +
> +#define PHY_POLL NO_IRQ
> #define PHY_IGNORE_INTERRUPT -2
>
> #define PHY_HAS_INTERRUPT 0x00000001
We really should run this by the larger kernel community
- k
^ permalink raw reply
* 2.6.19-rc2: known unfixed regressions (v2)
From: Adrian Bunk @ 2006-10-17 15:59 UTC (permalink / raw)
To: Linus Torvalds, Andrew Morton
Cc: Russell King, Thierry Vignaud, Jan Beulich, Andi Kleen,
linuxppc-dev, paulus, Jens Axboe, linux-visws-devel, Greg Banks,
Patrick Jefferson, Meelis Roos, Christian, art, linux-acpi,
Alan Cox, Michael S. Tsirkin, Ingo Molnar, jgarzik, Martin Lorenz,
len.brown, Olaf Hering, discuss, cpufreq, Alex Romosan,
Kenny Graunke, James.Bottomley, linux-fbdev-devel, linux-ide,
pazke, Jesper Juhl, Linux Kernel Mailing List, davej,
Mark Langsdorf
In-Reply-To: <Pine.LNX.4.64.0610130941550.3952@g5.osdl.org>
This email lists some known unfixed regressions in 2.6.19-rc2 compared
to 2.6.18 that are not yet fixed Linus' tree.
If you find your name in the Cc header, you are either submitter of one
of the bugs, maintainer of an affectected subsystem or driver, a patch
of you caused a breakage or I'm considering you in any other way possibly
involved with one or more of these issues.
Due to the huge amount of recipients, please trim the Cc when answering.
Subject : ppc prep boot hang
References : http://lkml.org/lkml/2006/10/14/58
Submitter : Meelis Roos <mroos@linux.ee>
Status : unknown
Subject : X60s: BUG()s, lose ACPI events after suspend/resume
References : http://lkml.org/lkml/2006/10/10/39
Submitter : Martin Lorenz <martin@lorenz.eu.org>
Status : unknown
Subject : T60 stops triggering any ACPI events
References : http://lkml.org/lkml/2006/10/4/425
http://lkml.org/lkml/2006/10/16/262
Submitter : "Michael S. Tsirkin" <mst@mellanox.co.il>
Status : unknown
Subject : x86_64: build error: unknown pseudo-op: `.cfi_signal_frame'
References : http://lkml.org/lkml/2006/10/16/8
Submitter : Ingo Molnar <mingo@elte.hu>
Caused-By : Jan Beulich <jbeulich@novell.com>
Andi Kleen <ak@suse.de>
commit adf1423698f00d00b267f7dca8231340ce7d65ef
Status : Jan: That is nothing I added, I suppose Andi did.
But the fix is obvious and trivial.
Subject : undefined reference to highest_possible_node_id
References : http://lkml.org/lkml/2006/9/4/233
http://lkml.org/lkml/2006/10/15/11
Submitter : Olaf Hering <olaf@aepfle.de>
Caused-By : Greg Banks <gnb@melbourne.sgi.com>
commit 0f532f3861d2c4e5aa7dcd33fb18e9975eb28457
Status : unknown
Subject : many ARM compile failures after the post -rc1 IRQ patches
References : http://lkml.org/lkml/2006/10/15/29
http://armlinux.simtec.co.uk/kautobuild/2.6.19-rc2/index.html
Submitter : Russell King <rmk+lkml@arm.linux.org.uk>
Caused-By : David Howells <dhowells@redhat.com>
Status : unknown
Subject : CONFIG_X86_VOYAGER=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown
Subject : CONFIG_X86_VISWS=y, CONFIG_SMP=n compile error
References : http://lkml.org/lkml/2006/10/7/51
Submitter : Jesper Juhl <jesper.juhl@gmail.com>
Caused-By : David Howells <dhowells@redhat.com>
commit 7d12e780e003f93433d49ce78cfedf4b4c52adc5
Status : unknown
Subject : sata-via doesn't detect anymore disks attached to VIA vt6421
References : http://bugzilla.kernel.org/show_bug.cgi?id=7255
Submitter : Thierry Vignaud <tvignaud@mandriva.com>
Status : unknown
Subject : SMP x86_64 boot problem
References : http://lkml.org/lkml/2006/9/28/330
http://lkml.org/lkml/2006/10/5/289
Submitter : art@usfltd.com
Status : submitter was asked to git bisect
result of bisecting seems to be wrong
Subject : monitor not active after boot
References : http://lkml.org/lkml/2006/10/5/338
Submitter : Olaf Hering <olaf@aepfle.de>
Caused-By : Antonino Daplas <adaplas@pol.net>
commit 346bc21026e7a92e1d7a4a1b3792c5e8b686133d
Status : unknown
Subject : unable to rip cd
References : http://lkml.org/lkml/2006/10/13/100
Submitter : Alex Romosan <romosan@sycorax.lbl.gov>
Status : unknown
Subject : ide-generic no longer finds marvell controller
References : http://bugzilla.kernel.org/show_bug.cgi?id=7353
Submitter : Kenny Graunke <kenny@whitecape.org>
Caused-By : Patrick Jefferson <henj@hp.com>
commit a4bea10eca68152e84ffc4eaeb9d20ec2ac34664
Handled-By : Alan Cox <alan@redhat.com>
Status : Alan is investigating
Subject : cpufreq not working on AMD K8
References : http://lkml.org/lkml/2006/10/10/114
Submitter : Christian <christiand59@web.de>
Handled-By : Mark Langsdorf <mark.langsdorf@amd.com>
Status : Mark is investigating
^ permalink raw reply
* Re: [Regression] cpu hotplug failed on kernel 2.6.19-rc2
From: Nathan Lynch @ 2006-10-17 16:12 UTC (permalink / raw)
To: Yao Fei Zhu; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <4534D7C6.2080402@cn.ibm.com>
Yao Fei Zhu wrote:
> Running cpu hotplug regression tsstcase lhcs_regression on kernel
> 2.6.19-rc2/IBM System p5 will fall into xmon.
Your subject implies this is a regression; what is the most recent
kernel that worked?
^ permalink raw reply
* Re: [Regression] cpu hotplug failed on kernel 2.6.19-rc2
From: Yao Fei Zhu @ 2006-10-17 16:14 UTC (permalink / raw)
To: Nathan Lynch; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20061017161251.GB18689@localdomain>
Nathan Lynch 写道:
> Yao Fei Zhu wrote:
>
>
>>Running cpu hotplug regression tsstcase lhcs_regression on kernel
>>2.6.19-rc2/IBM System p5 will fall into xmon.
>
>
> Your subject implies this is a regression; what is the most recent
> kernel that worked?
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
2.6.18 works. Not tested on 2.6.19-rc1.
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: David Woodhouse @ 2006-10-17 17:37 UTC (permalink / raw)
To: Andrey Volkov; +Cc: dedekind, Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <4534E078.9030301@varma-el.com>
On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
> No, MPC5200 could write any size chunks, but it must be aligned (same
> restrictions as in SH4), and this restriction applied only to LPB, but
> not SDRAM.
>
> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
> functions which MTD drivers exported, but jffs2_scan_dirent_node and
> friends - doesn't.
There are two modes of operation for JFFS2 scan. Either it can use the
MTD device's read() function to read from the flash into memory and scan
from there, or -- IF the flash can be accessed as if it were normal
memory -- it can use the point() method and skip the read() call by
using a pointer directly into the flash.
In your case, the flash cannot be accessed directly as if it were normal
memory. So your map driver probably shouldn't be allowing point() to
succeed.
Having said that, I'm not entirely sure we have the code set up so that
'simple' map drivers _can_ prevent point(). We may need to fix that.
--
dwmw2
^ permalink raw reply
* How does Linux treat memory above the "mem=" mark?
From: Howard, Marc @ 2006-10-17 18:04 UTC (permalink / raw)
To: Linuxppc-embedded
Hi,
I have a PPC440GX board with 512M of memory. I use "mem=3D496M" boot
argument to keep Linux from using the uppermost 16MB of memory. That
region of memory is instead used for hardware communications.
Occasionally however the CPU will read/write this space as well.
My questions concerns TLB entries. How does Linux define this region in
the TLB? Does it define this region as non-cacheable in the TLB? If
not, what is the correct way to define an area of memory that is outside
the OS's control as non-cacheable?
Thanks,
Marc W. Howard
marc.howard@kla-tencor.com
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Judith Lebzelter @ 2006-10-17 18:04 UTC (permalink / raw)
To: Randy Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <20061017094742.a61c4873.randy.dunlap@oracle.com>
Hi Randy,
There is another section in that function which depends on
'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
error, it does depend on some of the variables set in this section,
but not 'rd_size'. I think for consistancy it might be better to do
somthing like this(below)? Or else add the same ifdef down there...
Judith
Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
===================================================================
--- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
+++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
@@ -305,8 +305,10 @@
initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
initrd_below_start_ok = 1; // ramdisk in kernel space
ROOT_DEV = Root_RAM0;
+#if defined(CONFIG_BLK_DEV_RAM)
if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
+#endif /* CONFIG_BLK_DEV_RAM */
} else
#endif /* CONFIG_BLK_DEV_INITRD */
{
^ permalink raw reply
* [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy Dunlap @ 2006-10-17 16:47 UTC (permalink / raw)
To: ppcdev; +Cc: paulus
From: Randy Dunlap <randy.dunlap@oracle.com>
Fix build error for allmodconfig on powerpc:
arch/powerpc/platforms/built-in.o:(.toc+0x10b0): undefined reference to `rd_size'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/powerpc/platforms/iseries/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-2619-rc2-pv.orig/arch/powerpc/platforms/iseries/setup.c
+++ linux-2619-rc2-pv/arch/powerpc/platforms/iseries/setup.c
@@ -295,7 +295,7 @@ static void __init iSeries_init_early(vo
{
DBG(" -> iSeries_init_early()\n");
-#if defined(CONFIG_BLK_DEV_INITRD)
+#if defined(CONFIG_BLK_DEV_INITRD) && defined(CONFIG_BLK_DEV_RAM)
/*
* If the init RAM disk has been configured and there is
* a non-zero starting address for it, set it up
---
---
~Randy
^ permalink raw reply
* [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Randy Dunlap @ 2006-10-17 16:50 UTC (permalink / raw)
To: ppcdev; +Cc: paulus
From: Randy Dunlap <randy.dunlap@oracle.com>
Make allmodconfig .config build successfully by making VIOCONS
available only if VT=n.
Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
arch/powerpc/platforms/iseries/Kconfig | 2 +-
drivers/char/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2619-rc2-ppc.orig/drivers/char/Kconfig
+++ linux-2619-rc2-ppc/drivers/char/Kconfig
@@ -7,7 +7,7 @@ menu "Character devices"
config VT
bool "Virtual terminal" if EMBEDDED
select INPUT
- default y if !VIOCONS
+ default y if !PPC_ISERIES
---help---
If you say Y here, you will get support for terminal devices with
display and keyboard devices. These are called "virtual" because you
--- linux-2619-rc2-ppc.orig/arch/powerpc/platforms/iseries/Kconfig
+++ linux-2619-rc2-ppc/arch/powerpc/platforms/iseries/Kconfig
@@ -3,7 +3,7 @@ menu "iSeries device drivers"
depends on PPC_ISERIES
config VIOCONS
- tristate "iSeries Virtual Console Support (Obsolete)"
+ tristate "iSeries Virtual Console Support (Obsolete)" if !VT
help
This is the old virtual console driver for legacy iSeries.
You should use the iSeries Hypervisor Virtual Console
---
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Andrey Volkov @ 2006-10-17 20:16 UTC (permalink / raw)
To: David Woodhouse; +Cc: dedekind, Andrea Galbusera, linux-mtd, linuxppc-embedded
In-Reply-To: <1161106630.23666.109.camel@hades.cambridge.redhat.com>
David Woodhouse wrote:
> On Tue, 2006-10-17 at 17:54 +0400, Andrey Volkov wrote:
>> No, MPC5200 could write any size chunks, but it must be aligned (same
>> restrictions as in SH4), and this restriction applied only to LPB, but
>> not SDRAM.
>>
>> Also, I've in view that jffs2(jffs3 ?) read/write stuff already used
>> functions which MTD drivers exported, but jffs2_scan_dirent_node and
>> friends - doesn't.
>
> There are two modes of operation for JFFS2 scan. Either it can use the
> MTD device's read() function to read from the flash into memory and scan
> from there, or -- IF the flash can be accessed as if it were normal
> memory -- it can use the point() method and skip the read() call by
> using a pointer directly into the flash.
>
> In your case, the flash cannot be accessed directly as if it were normal
> memory. So your map driver probably shouldn't be allowing point() to
> succeed.
>
> Having said that, I'm not entirely sure we have the code set up so that
> 'simple' map drivers _can_ prevent point(). We may need to fix that.
David, thanks for an explanations (Artem already pointed me to this
jffs2 behavior).
--
Regards
Andrey
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-17 20:29 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
I agree. Just this patch, not my previous patch.
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-17 20:37 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
Yes, I agree, this is better. Just drop my patch 1/2.
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
>
--
~Randy
^ permalink raw reply
* Re: JFFS2 on Lite5200
From: Wolfgang Denk @ 2006-10-17 20:37 UTC (permalink / raw)
To: Andrea Galbusera; +Cc: linuxppc-embedded
In-Reply-To: <1161081183.22948.58.camel@localhost.localdomain>
In message <1161081183.22948.58.camel@localhost.localdomain> you wrote:
>
> I'm currently using linux-2.6.16 from denx on a Lite5200 V2.0. I need to
> access a JFFS2 filesystem on the onboard flash ( 16MB Am29L652D ).
We do NOT support the MPC5200 in the context of this kernel tree yet.
For the MPC5200, we still recommend to use the linuxppc_2_4_devel
tree.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The whole problem with the world is that fools and fanatics are
always so certain of themselves, but wiser people so full of doubts."
- Bertrand Russell
^ permalink raw reply
* [PATCH] e1000: Reset all functions after a PCI error
From: Linas Vepstas @ 2006-10-17 20:42 UTC (permalink / raw)
To: akpm, Jesse Brandeburg, Auke Kok; +Cc: linuxppc-dev, linux-pci, linux-kernel
Please apply and forward upstream.
--linas
During the handling of the PCI error recovery sequence,
the current e1000 driver erroneously blocks a device reset
for any but the first PCI function. It shouldn't -- this
is a cut-n-paste error from a different driver (which
tolerated only one hardware reset per hardware card).
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Auke Kok <auke-jan.h.kok@intel.com>
----
drivers/net/e1000/e1000_main.c | 4 ----
1 file changed, 4 deletions(-)
Index: linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c
===================================================================
--- linux-2.6.19-rc1-git11.orig/drivers/net/e1000/e1000_main.c 2006-10-17 15:02:25.000000000 -0500
+++ linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c 2006-10-17 15:03:35.000000000 -0500
@@ -4914,10 +4914,6 @@ static pci_ers_result_t e1000_io_slot_re
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
- /* Perform card reset only on one instance of the card */
- if (PCI_FUNC (pdev->devfn) != 0)
- return PCI_ERS_RESULT_RECOVERED;
-
e1000_reset(adapter);
E1000_WRITE_REG(&adapter->hw, WUS, ~0);
^ permalink raw reply
* Re: [PATCH] e1000: Reset all functions after a PCI error
From: Auke Kok @ 2006-10-17 20:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: akpm, Jesse Brandeburg, linux-kernel, linuxppc-dev, linux-pci
In-Reply-To: <20061017204206.GG6537@austin.ibm.com>
Linas Vepstas wrote:
> Please apply and forward upstream.
ACK
Jeff, please apply on top of today's fixes.
Auke
> --linas
>
> During the handling of the PCI error recovery sequence,
> the current e1000 driver erroneously blocks a device reset
> for any but the first PCI function. It shouldn't -- this
> is a cut-n-paste error from a different driver (which
> tolerated only one hardware reset per hardware card).
>
> Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
> Cc: Auke Kok <auke-jan.h.kok@intel.com>
>
> ----
> drivers/net/e1000/e1000_main.c | 4 ----
> 1 file changed, 4 deletions(-)
>
> Index: linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c
> ===================================================================
> --- linux-2.6.19-rc1-git11.orig/drivers/net/e1000/e1000_main.c 2006-10-17 15:02:25.000000000 -0500
> +++ linux-2.6.19-rc1-git11/drivers/net/e1000/e1000_main.c 2006-10-17 15:03:35.000000000 -0500
> @@ -4914,10 +4914,6 @@ static pci_ers_result_t e1000_io_slot_re
> pci_enable_wake(pdev, PCI_D3hot, 0);
> pci_enable_wake(pdev, PCI_D3cold, 0);
>
> - /* Perform card reset only on one instance of the card */
> - if (PCI_FUNC (pdev->devfn) != 0)
> - return PCI_ERS_RESULT_RECOVERED;
> -
> e1000_reset(adapter);
> E1000_WRITE_REG(&adapter->hw, WUS, ~0);
>
^ permalink raw reply
* Re: RFC: qe lib code location?
From: Dan Malek @ 2006-10-16 19:21 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-dev list, Li Yang, Kim Phillips
In-Reply-To: <F75246DE-A58C-43EA-875E-CD82A3668188@freescale.com>
On Oct 16, 2006, at 2:46 PM, Andy Fleming wrote:
> My reasoning is that, should Freescale decide to release a non-
> powerpc chip with a QUICC Engine,
Pigs will fly someday, too, but I'm not making plans for that :-)
If you are going to speculate, history shows there will more
likely be yet another version of some communication engine
before there will be a something other than a Power core
with one.
> .... Of course, all of this is pure speculation, so if
> there's a good reason *not* to put it in drivers/, we should probably
> just maintain the status quo.
I thought I provided some reasoning, but I suspect
speculation will prevail.........
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Stephen Rothwell @ 2006-10-18 1:19 UTC (permalink / raw)
To: Randy Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <20061017095003.c447d88a.randy.dunlap@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 605 bytes --]
On Tue, 17 Oct 2006 09:50:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>
> From: Randy Dunlap <randy.dunlap@oracle.com>
>
> Make allmodconfig .config build successfully by making VIOCONS
> available only if VT=n.
> Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
The problem with this is that we are moving toward being able to build a
single kernel with PPC_PSERIES and PPC_ISERIES (and others) all defined,
and this patch will stop Virtual terminal being built in that case.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Randy.Dunlap @ 2006-10-18 1:24 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppcdev, paulus
In-Reply-To: <20061018111935.a143164c.sfr@canb.auug.org.au>
Stephen Rothwell wrote:
> On Tue, 17 Oct 2006 09:50:03 -0700 Randy Dunlap <randy.dunlap@oracle.com> wrote:
>> From: Randy Dunlap <randy.dunlap@oracle.com>
>>
>> Make allmodconfig .config build successfully by making VIOCONS
>> available only if VT=n.
>> Using PPC_ISERIES in VT prevents kconfig "recursive" warning.
>
> The problem with this is that we are moving toward being able to build a
> single kernel with PPC_PSERIES and PPC_ISERIES (and others) all defined,
> and this patch will stop Virtual terminal being built in that case.
OK. Makes sense. Will you just build VT in that combo *series
config and not build VIOCONS? If so, that would still fix
"make allmodconfig" to build cleanly (I think).
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] ramdisk: make powerpc allmodconfig build
From: Michael Ellerman @ 2006-10-18 3:10 UTC (permalink / raw)
To: Judith Lebzelter; +Cc: Randy Dunlap, ppcdev, paulus
In-Reply-To: <20061017180447.GC822@shell0.pdx.osdl.net>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Tue, 2006-10-17 at 11:04 -0700, Judith Lebzelter wrote:
> Hi Randy,
>
> There is another section in that function which depends on
> 'CONFIG_BLK_DEV_INITRD' being defined. Although it does not throw an
> error, it does depend on some of the variables set in this section,
> but not 'rd_size'. I think for consistancy it might be better to do
> somthing like this(below)? Or else add the same ifdef down there...
>
> Judith
>
>
> Index: 2/linux/arch/powerpc/platforms/iseries/setup.c
> ===================================================================
> --- 2.orig/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:49:31.423551104 -0700
> +++ 2/linux/arch/powerpc/platforms/iseries/setup.c 2006-10-17 10:52:22.682515784 -0700
> @@ -305,8 +305,10 @@
> initrd_end = initrd_start + naca.xRamDiskSize * HW_PAGE_SIZE;
> initrd_below_start_ok = 1; // ramdisk in kernel space
> ROOT_DEV = Root_RAM0;
> +#if defined(CONFIG_BLK_DEV_RAM)
> if (((rd_size * 1024) / HW_PAGE_SIZE) < naca.xRamDiskSize)
> rd_size = (naca.xRamDiskSize * HW_PAGE_SIZE) / 1024;
> +#endif /* CONFIG_BLK_DEV_RAM */
> } else
> #endif /* CONFIG_BLK_DEV_INITRD */
> {
That code is bogus, we'll remove it entirely.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* [PATCH] Powerpc: Fix the warining message from the return value of function get_property
From: Zang Roy-r61911 @ 2006-10-18 3:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list
The following patch fixes the warning message from the return value of
function get_property().
Add const constrain for the return value of function get_property()
Signed-off-by: Roy Zang <tie-fei.zang@freescale.com>
--
diff --git a/arch/powerpc/sysdev/tsi108_dev.c b/arch/powerpc/sysdev/tsi108_dev.c
index 11de090..97f37ef 100644
--- a/arch/powerpc/sysdev/tsi108_dev.c
+++ b/arch/powerpc/sysdev/tsi108_dev.c
@@ -48,7 +48,7 @@ phys_addr_t get_csrbase(void)
tsi = of_find_node_by_type(NULL, "tsi-bridge");
if (tsi) {
unsigned int size;
- void *prop = get_property(tsi, "reg", &size);
+ const void *prop = get_property(tsi, "reg", &size);
tsi108_csr_base = of_translate_address(tsi, prop);
of_node_put(tsi);
};
@@ -79,7 +79,7 @@ static int __init tsi108_eth_of_init(voi
hw_info tsi_eth_data;
unsigned int *id;
unsigned int *phy_id;
- void *mac_addr;
+ const void *mac_addr;
phandle *ph;
memset(r, 0, sizeof(r));
^ permalink raw reply related
* Re: [PATCH 2/2] viocons: make powerpc allmodconfig build
From: Stephen Rothwell @ 2006-10-18 3:39 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: ppcdev, paulus
In-Reply-To: <4535824F.1020407@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Tue, 17 Oct 2006 18:24:31 -0700 "Randy.Dunlap" <randy.dunlap@oracle.com> wrote:
>
> OK. Makes sense. Will you just build VT in that combo *series
> config and not build VIOCONS? If so, that would still fix
> "make allmodconfig" to build cleanly (I think).
Yes, VIOCONS is now obsolete (it is replaced by HVC_ISERIES which doesn't
clash with VT), but it is used by the distros so I don't want to remove
it (yet).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox