Re: [PATCH] [POWERPC] i2c: fix build breakage introduced by OF helpers
From: Paul Mackerras [EMAIL PROTECTED] Date: Sat, 19 Apr 2008 15:22:37 +1000 David Miller writes: From: Paul Mackerras [EMAIL PROTECTED] Date: Sat, 19 Apr 2008 14:04:32 +1000 It's OK if this breaks the sparc64 allmodconfig build, I'll take care of this once it's merged in. It breaks the sparc32 allmodconfig build, which seems to be a concern. How do you suggest we fix that? I'll fix both sparc64 and sparc32 builds when I merge my sparc tree in. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] i2c: fix build breakage introduced by OF helpers
On Fri, 18 Apr 2008 23:11:28 -0700 (PDT), David Miller wrote: From: Paul Mackerras [EMAIL PROTECTED] Date: Sat, 19 Apr 2008 15:22:37 +1000 David Miller writes: From: Paul Mackerras [EMAIL PROTECTED] Date: Sat, 19 Apr 2008 14:04:32 +1000 It's OK if this breaks the sparc64 allmodconfig build, I'll take care of this once it's merged in. It breaks the sparc32 allmodconfig build, which seems to be a concern. How do you suggest we fix that? I'll fix both sparc64 and sparc32 builds when I merge my sparc tree in. Guys, you're doing things the wrong way around. Breaking things to fix them later is not OK, it's a pain for testers and also when bisecting the kernel. Everything should still work after merging the powerpc tree. Dave, if you need to loosen the dependency, you should do it yourself _after_ having changed whatever needs to be in the sparc32 and sparc64 trees so that loosening the dependency doesn't break anything. As far as I can see it's only a matter of changing one line in a Kconfig file, that's not exactly difficult to do it in the right order. Thanks, -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] i2c: fix build breakage introduced by OF helpers
From: Jean Delvare [EMAIL PROTECTED] Date: Sat, 19 Apr 2008 11:09:34 +0200 Guys, you're doing things the wrong way around. Breaking things to fix them later is not OK, it's a pain for testers and also when bisecting the kernel. Everything should still work after merging the powerpc tree. Dave, if you need to loosen the dependency, you should do it yourself _after_ having changed whatever needs to be in the sparc32 and sparc64 trees so that loosening the dependency doesn't break anything. As far as I can see it's only a matter of changing one line in a Kconfig file, that's not exactly difficult to do it in the right order. Fair enough. At least don't move this stuff under arch/powerpc as paulus originally had suggested. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/POWERPC] mpc5200: remove mpc5200b-* from compatible lists in dts files
The mpc5200b is a bug fix of the mpc5200 with a few incompatible changes. By rights, the current dts trees are the most correct, but in practical purposes there is no value in the 5200b devices having 2 compatible entries for each internal peripheral node. Freescale has done a good job of documenting exactly where the incompatibilities lie, so it restrict the extra compatible properties to devices with *documented* changes. And what happens when later an undocumented change is found? The device tree should always list the exact version of device used, even if all clients (i.e., the Linux kernel) only use the less-specific compatible value; that way, if a need to distinguish arises later (e.g., a model-specific bug workaround), a client can detect the exact model of device without needing a new device tree (that the client in general has no control over). Removing the extra 'b' fields makes the device trees smaller That's nice in general, but it hardly overrides more serious concerns. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [POWERPC] 4xx: Add NOR FLASH entries to Canyonlands and Glacier dts
This patch adds default NOR entries to the AMCC Canyonlands (460EX)
and Glacier (460GT) dts files.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/canyonlands.dts | 37 +
arch/powerpc/boot/dts/glacier.dts | 37 +
2 files changed, 74 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index 6f3d38a..3963412 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -142,8 +142,45 @@
#address-cells = 2;
#size-cells = 1;
clock-frequency = 0; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
interrupts = 6 4;
interrupt-parent = UIC1;
+
+ [EMAIL PROTECTED],0 {
+ compatible = amd,s29gl512n,
cfi-flash;
+ bank-width = 2;
+ reg = 0 00 400;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0 1e;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 1e 2;
+ };
+ [EMAIL PROTECTED] {
+ label = ramdisk;
+ reg = 20 140;
+ };
+ [EMAIL PROTECTED] {
+ label = jffs2;
+ reg = 160 40;
+ };
+ [EMAIL PROTECTED] {
+ label = user;
+ reg = 1a0 256;
+ };
+ [EMAIL PROTECTED] {
+ label = env;
+ reg = 3f6 4;
+ };
+ [EMAIL PROTECTED] {
+ label = u-boot;
+ reg = 3fa 6;
+ };
+ };
};
UART0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index 958a5ca..0f2fc07 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -145,8 +145,45 @@
#address-cells = 2;
#size-cells = 1;
clock-frequency = 0; /* Filled in by U-Boot */
+ /* ranges property is supplied by U-Boot */
interrupts = 6 4;
interrupt-parent = UIC1;
+
+ [EMAIL PROTECTED],0 {
+ compatible = amd,s29gl512n,
cfi-flash;
+ bank-width = 2;
+ reg = 0 00 400;
+ #address-cells = 1;
+ #size-cells = 1;
+ [EMAIL PROTECTED] {
+ label = kernel;
+ reg = 0 1e;
+ };
+ [EMAIL PROTECTED] {
+ label = dtb;
+ reg = 1e 2;
+ };
+ [EMAIL PROTECTED] {
+ label = ramdisk;
+ reg = 20 140;
+ };
+ [EMAIL PROTECTED] {
+ label = jffs2;
+ reg = 160 40;
+ };
+
[PATCH] [POWERPC] 4xx: Fix 460GT support to not enable FPU
The AMCC 460GT doesn't have an FPU so let's not enable support for it.
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
arch/powerpc/kernel/cpu_setup_44x.S |1 -
arch/powerpc/kernel/cputable.c |4 +---
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/cpu_setup_44x.S
b/arch/powerpc/kernel/cpu_setup_44x.S
index 5465e8d..e3623e3 100644
--- a/arch/powerpc/kernel/cpu_setup_44x.S
+++ b/arch/powerpc/kernel/cpu_setup_44x.S
@@ -33,7 +33,6 @@ _GLOBAL(__setup_cpu_440grx)
mtlrr4
blr
_GLOBAL(__setup_cpu_460ex)
-_GLOBAL(__setup_cpu_460gt)
b __init_fpu_44x
_GLOBAL(__setup_cpu_440gx)
_GLOBAL(__setup_cpu_440spe)
diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/cputable.c
index 26ffb44..36080d4 100644
--- a/arch/powerpc/kernel/cputable.c
+++ b/arch/powerpc/kernel/cputable.c
@@ -37,7 +37,6 @@ extern void __setup_cpu_440gx(unsigned long offset, struct
cpu_spec* spec);
extern void __setup_cpu_440grx(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_440spe(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_460ex(unsigned long offset, struct cpu_spec* spec);
-extern void __setup_cpu_460gt(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_603(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_604(unsigned long offset, struct cpu_spec* spec);
extern void __setup_cpu_750(unsigned long offset, struct cpu_spec* spec);
@@ -1416,10 +1415,9 @@ static struct cpu_spec __initdata cpu_specs[] = {
.pvr_value = 0x1302,
.cpu_name = 460GT,
.cpu_features = CPU_FTRS_44X,
- .cpu_user_features = COMMON_USER_BOOKE |
PPC_FEATURE_HAS_FPU,
+ .cpu_user_features = COMMON_USER_BOOKE,
.icache_bsize = 32,
.dcache_bsize = 32,
- .cpu_setup = __setup_cpu_460gt,
.machine_check = machine_check_440A,
.platform = ppc440,
},
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic
Original-Nachricht Datum: Thu, 17 Apr 2008 21:57:05 -0500 (CDT) Von: Kumar Gala [EMAIL PROTECTED] An: Paul Mackerras [EMAIL PROTECTED] CC: linuxppc-dev@ozlabs.org Betreff: [PATCH] [POWERPC] Port fixmap from x86 and use for kmap_atomic The fixmap code from x86 allows us to have compile time virtual addresses that we change the physical addresses of at run time. ... +/* + * Here we define all the compile-time 'special' virtual + * addresses. The point is to have a constant address at + * compile time, but to set the physical address only + * in the boot process. We allocate these special addresses + * from the end of virtual memory (0xf000) backwards. + * Also this lets us do fail-safe vmalloc(), we + * can guarantee that these special addresses and + * vmalloc()-ed addresses never overlap. I don't understand how highmem works, but I'm just interested to know, if this implementation could conflict somehow with the non coherent DMA implementation in dma-noncoherent.c (which uses address space from 0xff10 to 0xff30 for DMA memory). On the other side could dma-noncoherent.c benefit from fixmaps so that it isn't necessary to configure a start address for DMA allocations? Thanks! best regards, Gerhard -- Psst! Geheimtipp: Online Games kostenlos spielen bei den GMX Free Games! http://games.entertainment.gmx.net/de/entertainment/games/free ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] i2c: fix build breakage introduced by OF helpers
Jean Delvare writes: Guys, you're doing things the wrong way around. Breaking things to fix them later is not OK, it's a pain for testers and also when bisecting the kernel. Everything should still work after merging the powerpc tree. Dave, if you need to loosen the dependency, you should do it yourself _after_ having changed whatever needs to be in the sparc32 and sparc64 trees so that loosening the dependency doesn't break anything. As far as I can see it's only a matter of changing one line in a Kconfig file, that's not exactly difficult to do it in the right order. You're right. I'll put in a dependency on PPC_OF for now and Dave can take it out once sparc32/64 have irq_of_parse_and_map etc. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
Grant Likely wrote: On Fri, Apr 18, 2008 at 12:11 PM, Matt Sealey [EMAIL PROTECTED] wrote: Juergen Beisert wrote: BTW, is anyone trying to shepherd this driver into the ALSA tree? Its out of my area of expertise and responsibility, so I haven't been pursuing it. We (well, I) were going to try but we got some oopses; from one thing or another, but with Juergen's fixes and cell-index in place, now it plays audio. Now it can be pushed to ALSA on that basis, but I'm still trying to get my head around where we need to throw patches and if it goes into ALSA Drivers first or the kernel or both? It's kind of convoluted compared to the ease of just CC'ing netdev or linux-ide.. If you want to push it, please do, but also I guess it'll need to be bundled with the cell-index patch for the fixups (we couldn't get it to make the property for some odd reason) or a change to using addresses in the driver for PSC selection (Juergen's original patch did this anyway) -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Patches added to powerpc.git master and powerpc-next branches
Kumar Gala writes: [POWERPC] 85xx: Add support for relocatble kernel (and booting at non- zero) Should be OK to go though probably not in the first batch. I want to look through it carefully again since it's touching code that is common to a lot of platforms. The patch description looks reasonable as to what it explains but the english could use a touch-up here or there (e.g. a physical address that is module 256M doesn't actually mean anything; a physical address that is 0 modulo 256M would be correct). [POWERPC] Port fixmap from x86 and use for kmap_atomic Once again I want to go through it carefully and understand how it all works, and in particular understand things like the way it ensures that the base address for the kmap region is aligned to a 4M boundary so all the kmap ptes are in a single page (assuming it does :). Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote: Update dts files to current format Is it somehow possible that this device tree stuff is *not* changed over and over again and break everything out there? When people have not even agreed on basic things like decimal vs. hex numbers, the whole idea should be developed out-of-tree, then stabilize and *then* be submitted to the Linux mainline. Is it also really necessary to change like gpt vs. timer and pic vs. interrupt-controller all the time? If you compare the last mainline kernels, each one got a fundamental change in the naming, each time breaking anyone who doesn't have his stuff in the mainline yet. Sorry, but this is simply annoying, and the whole the only thing we have to do is to define it once and be done then is crap. Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [v3][POWERPC] refactor dcr code
On Fri, 18 Apr 2008 14:55:03 -0700
Stephen Neuendorffer [EMAIL PROTECTED] wrote:
Previously, dcr support was configured at compile time to either using
MMIO or native dcr instructions. Although this works for most
platforms, it fails on FPGA platforms:
1) Systems may include more than one dcr bus.
2) Systems may be native dcr capable and still use memory mapped dcr
interface.
This patch provides runtime support based on the device trees for the
case where CONFIG_PPC_DCR_MMIO and CONFIG_PPC_DCR_NATIVE are both
selected. Previously, this was a poorly defined configuration, which
happened to provide NATIVE support. The runtime selection is made
based on the dcr controller having a 'dcr-access-method' attribute
in the device tree. If only one of the above options is selected,
then the code uses #defines to select only the used code in order to
avoid introducing overhead in existing usage.
Signed-off-by: Stephen Neuendorffer [EMAIL PROTECTED]
Hi Stephen,
Sorry for the late review. See some comments below. Mostly minor
stuff and I think the general direction here is good.
diff --git a/arch/powerpc/sysdev/dcr.c b/arch/powerpc/sysdev/dcr.c
index 437e48d..d3de0ff 100644
--- a/arch/powerpc/sysdev/dcr.c
+++ b/arch/powerpc/sysdev/dcr.c
@@ -23,6 +23,68 @@
#include asm/prom.h
#include asm/dcr.h
+#if defined(CONFIG_PPC_DCR_NATIVE) defined(CONFIG_PPC_DCR_MMIO)
+
+bool dcr_map_ok_generic(dcr_host_t host)
+{
+ if (host.type == INVALID)
+ return 0;
+ else if (host.type == NATIVE)
+ return dcr_map_ok_native(host.host.native);
+ else
+ return dcr_map_ok_mmio(host.host.mmio);
+}
+EXPORT_SYMBOL_GPL(dcr_map_ok_generic);
+
+dcr_host_t dcr_map_generic(struct device_node *dev,
+unsigned int dcr_n,
+unsigned int dcr_c)
+{
+ dcr_host_t host;
+ const char *prop = of_get_property(dev, dcr-access-method, NULL);
+
+ if (!strcmp(prop, native)) {
+ host.type = NATIVE;
+ host.host.native = dcr_map_native(dev, dcr_n, dcr_c);
+ } else if (!strcmp(prop, mmio)) {
+ host.type = MMIO;
+ host.host.mmio = dcr_map_mmio(dev, dcr_n, dcr_c);
+ } else
+ host.type = INVALID;
+
+ return host;
+}
+EXPORT_SYMBOL_GPL(dcr_map_generic);
+
+void dcr_unmap_generic(dcr_host_t host, unsigned int dcr_c)
+{
+ if (host.type == NATIVE)
+ dcr_unmap_native(host.host.native, dcr_c);
+ else
+ dcr_unmap_mmio(host.host.mmio, dcr_c);
What happens if host.type == INVALID? Same question for the other
accessors in dcr_*_generic.
snip
diff --git a/include/asm-powerpc/dcr-generic.h
b/include/asm-powerpc/dcr-generic.h
new file mode 100644
index 000..0ee74fb
--- /dev/null
+++ b/include/asm-powerpc/dcr-generic.h
@@ -0,0 +1,49 @@
snip
+enum host_type_t {MMIO, NATIVE, INVALID};
Should these be DCR_HOST_MMIO, DCR_HOST_NATIVE, DCR_HOST_INVALID?
I worry about the generic nature of the names.
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 04/15] [PPC] minor irq handler cleanups
On Apr 18, 2008, at 6:22 PM, Jeff Garzik wrote: - whitespace cleanups - remove pointless prototype (uses always follow func implementation) - 'irq' argument is often used purely as a local variable. rename argument to 'dummy' and define 'irq' as local to make this plain. - remove pointless casts from void* This change's main purpose is to prepare for the patchset in jgarzik/misc-2.6.git#irq-remove, that explores removal of the never-used 'irq' argument in each interrupt handler. Signed-off-by: Jeff Garzik [EMAIL PROTECTED] arch/ppc is pretty much left for dead at this point. I'm guessing we will end up removing it 2.6.27 if we follow through with our plans of killing it this summer. Acked-by: Kumar Gala [EMAIL PROTECTED] - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [PPC] 4xx: Fix arch/ppc 440 builds
Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate definition in include/asm-ppc/mmu.h that caused the build to fail. This removes the duplicate definition in arch/ppc. Signed-off-by: Josh Boyer [EMAIL PROTECTED] --- include/asm-ppc/mmu.h |2 -- 1 file changed, 2 deletions(-) --- linux-2.6.orig/include/asm-ppc/mmu.h +++ linux-2.6/include/asm-ppc/mmu.h @@ -15,10 +15,8 @@ * physical need a larger than native word size type. -Matt */ #ifndef CONFIG_PHYS_64BIT -typedef unsigned long phys_addr_t; #define PHYS_FMT %.8lx #else -typedef unsigned long long phys_addr_t; extern phys_addr_t fixup_bigphys_addr(phys_addr_t, phys_addr_t); #define PHYS_FMT %16Lx #endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
removal of arch/ppc in 2.6.27?
This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. PPC_PREPe6xx PQ2ADS 82xxin arch/powerpc? TQM8260 82xx CPCI690 e6xx/mv64x60 EV64260 e6xx/mv64x60 CHESTNUTe6xx/mv64x60 LOPEC e6xx KATANA e6xx/mv64x60 HDPUe6xx/mv64x60 MVME5100e6xx PAL4e6xx POWERPMC250 e6xx PPLUS e6xx PRPMC750e6xx PRPMC800e6xx RADSTONE_PPC7D e6xx SANDPOINT e6xx SBC82xx 82xx SPRUCE e6xx LITE520052xx EV64360 e6xx/mv64x60 MPC86XADS 8xx in arch/powerpc MPC885ADS 8xx in arch/powerpc ADS8272 82xxin arch/powerpc 4xx: BAMBOO 44x in arch/powerpc CPCI405 40x EBONY 44x in arch/powerpc EP405 40x in arch/powerpc BUBINGA 40x LUAN44x YUCCA 44x OCOTEA 44x REDWOOD_5 40x REDWOOD_6 40x SYCAMORE40x TAISHAN 44x in arch/powerpc WALNUT 40x in arch/powerpc XILINX_ML30040x XILINX_ML40340x - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [PPC] 4xx: Fix arch/ppc 440 builds
On Sat, 2008-04-19 at 10:26 -0500, Josh Boyer wrote: Commit d04ceb3fc294ea2c4f538a04343f3a473953a3b0 moved phys_addr_t definitions to include/asm-powerpc/types.h. However, arch/ppc 440 builds had a duplicate definition in include/asm-ppc/mmu.h that caused the build to fail. This removes the duplicate definition in arch/ppc. Signed-off-by: Josh Boyer [EMAIL PROTECTED] Ignore this. The patch is correct but the subject is misleading because there is another commit that breaks arch/ppc builds for 440. I'll resend once I fix that as well. I hate arch/ppc. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
On Sat, Apr 19, 2008 at 7:36 AM, Robert Schwebel [EMAIL PROTECTED] wrote: On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote: Update dts files to current format Is it somehow possible that this device tree stuff is *not* changed over and over again and break everything out there? When people have not even agreed on basic things like decimal vs. hex numbers, the whole idea should be developed out-of-tree, then stabilize and *then* be submitted to the Linux mainline. Is it also really necessary to change like gpt vs. timer and pic vs. interrupt-controller all the time? If you compare the last mainline kernels, each one got a fundamental change in the naming, each time breaking anyone who doesn't have his stuff in the mainline yet. Sorry, but this is simply annoying, and the whole the only thing we have to do is to define it once and be done then is crap. Changing to dts-v1 does *not* break old stuff. It is just a source format change. Neither does the RFC patch for removing the fsl,mpc5200b- compatible strings. I have no intention of breaking older device trees. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [PPC] Remove mpc8272 ads board from arch/ppc
We have a board port in arch/powerpc so we dont need this one anymore. Signed-off-by: Kumar Gala [EMAIL PROTECTED] --- Will push via git tree. Removed defconfig diff to shorten patch. arch/ppc/8260_io/fcc_enet.c | 19 +- arch/ppc/Kconfig | 19 +- arch/ppc/configs/ads8272_defconfig| 930 - arch/ppc/platforms/Makefile |2 - arch/ppc/platforms/mpc8272ads_setup.c | 367 - arch/ppc/platforms/pq2ads.c | 53 -- arch/ppc/platforms/pq2ads.h | 94 arch/ppc/platforms/pq2ads_pd.h| 32 -- arch/ppc/syslib/m8260_setup.c |6 - arch/ppc/syslib/m82xx_pci.c | 38 -- include/asm-ppc/mpc8260.h |4 - 11 files changed, 2 insertions(+), 1562 deletions(-) delete mode 100644 arch/ppc/configs/ads8272_defconfig delete mode 100644 arch/ppc/platforms/mpc8272ads_setup.c delete mode 100644 arch/ppc/platforms/pq2ads.c delete mode 100644 arch/ppc/platforms/pq2ads.h delete mode 100644 arch/ppc/platforms/pq2ads_pd.h diff --git a/arch/ppc/8260_io/fcc_enet.c b/arch/ppc/8260_io/fcc_enet.c index bcc3aa9..d38b57e 100644 --- a/arch/ppc/8260_io/fcc_enet.c +++ b/arch/ppc/8260_io/fcc_enet.c @@ -165,9 +165,6 @@ static int fcc_enet_set_mac_address(struct net_device *dev, void *addr); #ifdef CONFIG_SBC82xx #define F1_RXCLK 9 #define F1_TXCLK 10 -#elif defined(CONFIG_ADS8272) -#define F1_RXCLK 11 -#define F1_TXCLK 10 #else #define F1_RXCLK 12 #define F1_TXCLK 11 @@ -175,13 +172,8 @@ static int fcc_enet_set_mac_address(struct net_device *dev, void *addr); /* FCC2 Clock Source Configuration. There are board specific. Can only choose from CLK13-16 */ -#ifdef CONFIG_ADS8272 -#define F2_RXCLK 15 -#define F2_TXCLK 16 -#else #define F2_RXCLK 13 #define F2_TXCLK 14 -#endif /* FCC3 Clock Source Configuration. There are board specific. Can only choose from CLK13-16 */ @@ -289,10 +281,7 @@ static int fcc_enet_set_mac_address(struct net_device *dev, void *addr); /* TQM8260 has MDIO and MDCK on PC30 and PC31 respectively */ #define PC_MDIO((uint)0x0002) #define PC_MDCK((uint)0x0001) -#elif defined(CONFIG_ADS8272) -#define PC_MDIO((uint)0x2000) -#define PC_MDCK((uint)0x1000) -#elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) || defined(CONFIG_PQ2FADS) +#elif defined(CONFIG_EST8260) || defined(CONFIG_ADS8260) #define PC_MDIO((uint)0x0040) #define PC_MDCK((uint)0x0020) #else @@ -2118,11 +2107,6 @@ init_fcc_startup(fcc_info_t *fip, struct net_device *dev) printk(Can't get FCC IRQ %d\n, fip-fc_interrupt); #ifdef PHY_INTERRUPT -#ifdef CONFIG_ADS8272 - if (request_irq(PHY_INTERRUPT, mii_link_interrupt, IRQF_SHARED, - mii, dev) 0) - printk(KERN_CRIT Can't get MII IRQ %d\n, PHY_INTERRUPT); -#else /* Make IRQn edge triggered. This does not work if PHY_INTERRUPT is * on Port C. */ @@ -2132,7 +2116,6 @@ init_fcc_startup(fcc_info_t *fip, struct net_device *dev) if (request_irq(PHY_INTERRUPT, mii_link_interrupt, 0, mii, dev) 0) printk(KERN_CRIT Can't get MII IRQ %d\n, PHY_INTERRUPT); -#endif #endif /* PHY_INTERRUPT */ /* Set GFMR to enable Ethernet operating mode. diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig index abc877f..3fc45e2 100644 --- a/arch/ppc/Kconfig +++ b/arch/ppc/Kconfig @@ -666,9 +666,6 @@ config TQM8260 End of Life: not yet :-) URL: http://www.denx.de/PDF/TQM82xx_SPEC_Rev005.pdf -config ADS8272 - bool ADS8272 - config PQ2FADS bool Freescale-PQ2FADS help @@ -698,11 +695,6 @@ config EV64360 platform. endchoice -config PQ2ADS - bool - depends on ADS8272 - default y - config TQM8xxL bool depends on 8xx (TQM823L || TQM850L || FPS850L || TQM855L || TQM860L) @@ -725,15 +717,6 @@ config 8260 this option means that you wish to build a kernel for a machine with an 8260 class CPU. -config 8272 - bool - depends on 6xx - default y if ADS8272 - select 8260 - help - The MPC8272 CPM has a different internal dpram setup than other CPM2 - devices - config CPM1 bool depends on 8xx @@ -1069,7 +1052,7 @@ config PCI_8260 config 8260_PCI9 bool Enable workaround for MPC826x erratum PCI 9 - depends on PCI_8260 !ADS8272 + depends on PCI_8260 default y choice diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile index 40f53fb..ef74a7b 100644 --- a/arch/ppc/platforms/Makefile +++ b/arch/ppc/platforms/Makefile @@ -4,7 +4,6 @@ obj-$(CONFIG_PPC_PREP) += prep_pci.o prep_setup.o
[PATCH] [PPC] Remove mpc885ads and mpc86x ads boards from arch/ppc
We have a board port in arch/powerpc so we dont need this one anymore.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Will push via git tree. Removed defconfig diff to shorten patch.
arch/ppc/8xx_io/enet.c| 23 --
arch/ppc/Kconfig | 63
arch/ppc/configs/mpc86x_ads_defconfig | 633 -
arch/ppc/configs/mpc885ads_defconfig | 622
arch/ppc/platforms/Makefile |2 -
arch/ppc/platforms/fads.h | 25 --
arch/ppc/platforms/mpc885ads.h| 93 -
arch/ppc/platforms/mpc885ads_setup.c | 476 -
arch/ppc/syslib/m8xx_setup.c | 10 -
include/asm-ppc/mpc8xx.h |4 -
10 files changed, 0 insertions(+), 1951 deletions(-)
delete mode 100644 arch/ppc/configs/mpc86x_ads_defconfig
delete mode 100644 arch/ppc/configs/mpc885ads_defconfig
delete mode 100644 arch/ppc/platforms/mpc885ads.h
delete mode 100644 arch/ppc/platforms/mpc885ads_setup.c
diff --git a/arch/ppc/8xx_io/enet.c b/arch/ppc/8xx_io/enet.c
index c6d047a..5899aea 100644
--- a/arch/ppc/8xx_io/enet.c
+++ b/arch/ppc/8xx_io/enet.c
@@ -946,29 +946,6 @@ static int __init scc_enet_init(void)
*((volatile uint *)BCSR1) = ~BCSR1_ETHEN;
#endif
-#ifdef CONFIG_MPC885ADS
-
- /* Deassert PHY reset and enable the PHY.
-*/
- {
- volatile uint __iomem *bcsr = ioremap(BCSR_ADDR, BCSR_SIZE);
- uint tmp;
-
- tmp = in_be32(bcsr + 1 /* BCSR1 */);
- tmp |= BCSR1_ETHEN;
- out_be32(bcsr + 1, tmp);
- tmp = in_be32(bcsr + 4 /* BCSR4 */);
- tmp |= BCSR4_ETH10_RST;
- out_be32(bcsr + 4, tmp);
- iounmap(bcsr);
- }
-
- /* On MPC885ADS SCC ethernet PHY defaults to the full duplex mode
-* upon reset. SCC is set to half duplex by default. So this
-* inconsistency should be better fixed by the software.
-*/
-#endif
-
dev-base_addr = (unsigned long)ep;
#if 0
dev-name = CPM_ENET;
diff --git a/arch/ppc/Kconfig b/arch/ppc/Kconfig
index 3fc45e2..0f1863e 100644
--- a/arch/ppc/Kconfig
+++ b/arch/ppc/Kconfig
@@ -372,22 +372,6 @@ config MPC8XXFADS
bool FADS
select FADS
-config MPC86XADS
- bool MPC86XADS
- help
- MPC86x Application Development System by Freescale Semiconductor.
- The MPC86xADS is meant to serve as a platform for s/w and h/w
- development around the MPC86X processor families.
- select FADS
-
-config MPC885ADS
- bool MPC885ADS
- help
- Freescale Semiconductor MPC885 Application Development System (ADS).
- Also known as DUET.
- The MPC885ADS is meant to serve as a platform for s/w and h/w
- development around the MPC885 processor family.
-
config TQM823L
bool TQM823L
help
@@ -479,53 +463,6 @@ config WINCEPT
endchoice
-menu Freescale Ethernet driver platform-specific options
- depends on FS_ENET
-
- config MPC8xx_SECOND_ETH
- bool Second Ethernet channel
- depends on (MPC885ADS || MPC86XADS)
- default y
- help
- This enables support for second Ethernet on MPC885ADS and MPC86xADS
boards.
- The latter will use SCC1, for 885ADS you can select it below.
-
- choice
- prompt Second Ethernet channel
- depends on MPC8xx_SECOND_ETH
- default MPC8xx_SECOND_ETH_FEC2
-
- config MPC8xx_SECOND_ETH_FEC2
- bool FEC2
- depends on MPC885ADS
- help
- Enable FEC2 to serve as 2-nd Ethernet channel. Note that SMC2
- (often 2-nd UART) will not work if this is enabled.
-
- config MPC8xx_SECOND_ETH_SCC1
- bool SCC1
- depends on MPC86XADS
- select MPC8xx_SCC_ENET_FIXED
- help
- Enable SCC1 to serve as 2-nd Ethernet channel. Note that SMC1
- (often 1-nd UART) will not work if this is enabled.
-
- config MPC8xx_SECOND_ETH_SCC3
- bool SCC3
- depends on MPC885ADS
- help
- Enable SCC3 to serve as 2-nd Ethernet channel. Note that SMC1
- (often 1-nd UART) will not work if this is enabled.
-
- endchoice
-
- config MPC8xx_SCC_ENET_FIXED
- depends on MPC8xx_SECOND_ETH_SCC
- default n
- bool Use fixed MII-less mode for SCC Ethernet
-
-endmenu
-
choice
prompt Machine Type
depends on 6xx
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
index ef74a7b..6260231 100644
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -23,5 +23,3 @@ obj-$(CONFIG_SBC82xx) += sbc82xx.o
obj-$(CONFIG_SPRUCE) += spruce.o
obj-$(CONFIG_LITE5200)
Re: RFC: MPC5200 PSC AC97 driver
On Sat, Apr 19, 2008 at 6:02 AM, Matt Sealey [EMAIL PROTECTED] wrote: Grant Likely wrote: On Fri, Apr 18, 2008 at 12:11 PM, Matt Sealey [EMAIL PROTECTED] wrote: Juergen Beisert wrote: BTW, is anyone trying to shepherd this driver into the ALSA tree? Its out of my area of expertise and responsibility, so I haven't been pursuing it. We (well, I) were going to try but we got some oopses; from one thing or another, but with Juergen's fixes and cell-index in place, now it plays audio. Now it can be pushed to ALSA on that basis, but I'm still trying to get my head around where we need to throw patches and if it goes into ALSA Drivers first or the kernel or both? It's kind of convoluted compared to the ease of just CC'ing netdev or linux-ide.. If you want to push it, please do, but also I guess it'll need to be bundled with the cell-index patch for the fixups (we couldn't get it to make the property for some odd reason) or a change to using addresses in the driver for PSC selection (Juergen's original patch did this anyway) I can pick up the cell-index patch, but I won't pick up the ALSA stuff; that's not my tree. Post the driver patch to the alsa list (but still cc linuxppc and me). The driver needs to go into ALSA drivers first. The kernel is updated from there. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: RFC: MPC5200 PSC AC97 driver
On Fri, Apr 18, 2008 at 9:43 AM, Peter Czanik [EMAIL PROTECTED] wrote:
Hello,
factory:/usr/src/linux-2.6.25 # diff -u
arch/powerpc/kernel/prom_init.c.orig arch/powerpc/kernel/prom_init.c
--- arch/powerpc/kernel/prom_init.c.orig2008-04-18
13:55:07.0 +0200
+++ arch/powerpc/kernel/prom_init.c 2008-04-18 16:26:51.0 +0200
@@ -2212,6 +2212,7 @@
static void __init fixup_device_tree_efika(void)
{
+ int sound_ci = 1;
int sound_irq[3] = { 2, 2, 0 };
int bcomm_irq[3*16] = { 3,0,0, 3,1,0, 3,2,0, 3,3,0,
3,4,0, 3,5,0, 3,6,0, 3,7,0,
@@ -2257,6 +2258,8 @@
rv = prom_getprop(node, interrupts, prop, sizeof(prop));
if (rv == PROM_ERROR) {
prom_printf(Adding sound interrupts property\n);
+prom_setprop(node, /builtin/sound, cell-index,
+ sound_ci, sizeof(int));
prom_setprop(node, /builtin/sound, interrupts,
sound_irq, sizeof(sound_irq));
}
This probably isn't the ideal solution; but I've got no objection to
bringing it in as a work around until someone can make the driver
cleaner.
However, this change needs to be more robust. It must first check if
the cell-index property already exists before trying to create it
(just like how adding the interrupts property works).
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC/POWERPC] mpc5200: remove mpc5200b-* from compatible lists in dts files
On Sat, Apr 19, 2008 at 3:23 AM, Segher Boessenkool [EMAIL PROTECTED] wrote: The mpc5200b is a bug fix of the mpc5200 with a few incompatible changes. By rights, the current dts trees are the most correct, but in practical purposes there is no value in the 5200b devices having 2 compatible entries for each internal peripheral node. Freescale has done a good job of documenting exactly where the incompatibilities lie, so it restrict the extra compatible properties to devices with *documented* changes. And what happens when later an undocumented change is found? The device tree should always list the exact version of device used, even if all clients (i.e., the Linux kernel) only use the less-specific compatible value; that way, if a need to distinguish arises later (e.g., a model-specific bug workaround), a client can detect the exact model of device without needing a new device tree (that the client in general has no control over). Yes, I fully agree and understand that. However, even that doesn't fully solve the problem. At what level do you stop trying to describe the device versions in the device tree? What about the case where an earlier silicon version has an undocumented errata? At some point, compatible doesn't help us and we need to resort to looking at other factors (like PVR/SVR) to determine what the device really is. Early on I decided to differentiate between the 5200 and the 5200b; however, from a practical sense they really are the same part and there is no practical advantage to differentiating between them. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Add compat handler for PTRACE_GETSIGINFO
Current versions of gdb require a working implementation of
PTRACE_GETSIGINFO for proper watchpoint support. Since struct siginfo
contains pointers it must be converted when passed to a 32-bit debugger.
Signed-off-by: Andreas Schwab [EMAIL PROTECTED]
---
arch/powerpc/kernel/ppc32.h|2 ++
arch/powerpc/kernel/ptrace32.c | 27 +++
2 files changed, 29 insertions(+)
--- linux-2.6.25.orig/arch/powerpc/kernel/ppc32.h 2006-01-03
17:04:01.0 +0100
+++ linux-2.6.25/arch/powerpc/kernel/ppc32.h2008-04-18 19:28:55.0
+0200
@@ -135,4 +135,6 @@ struct ucontext32 {
struct mcontext32 uc_mcontext;
};
+extern int copy_siginfo_to_user32(struct compat_siginfo __user *d, siginfo_t
*s);
+
#endif /* _PPC64_PPC32_H */
--- linux-2.6.25.orig/arch/powerpc/kernel/ptrace32.c2008-02-11
19:12:25.0 +0100
+++ linux-2.6.25/arch/powerpc/kernel/ptrace32.c 2008-04-18 19:31:20.0
+0200
@@ -29,12 +29,15 @@
#include linux/security.h
#include linux/signal.h
#include linux/compat.h
+#include linux/elf.h
#include asm/uaccess.h
#include asm/page.h
#include asm/pgtable.h
#include asm/system.h
+#include ppc32.h
+
/*
* does not yet catch signals sent when the child dies.
* in exit.c or in signal.c.
@@ -64,6 +67,27 @@ static long compat_ptrace_old(struct tas
return -EPERM;
}
+static int compat_ptrace_getsiginfo(struct task_struct *child,
compat_siginfo_t __user *data)
+{
+ siginfo_t lastinfo;
+ int error = -ESRCH;
+
+ read_lock(tasklist_lock);
+ if (likely(child-sighand != NULL)) {
+ error = -EINVAL;
+ spin_lock_irq(child-sighand-siglock);
+ if (likely(child-last_siginfo != NULL)) {
+ lastinfo = *child-last_siginfo;
+ error = 0;
+ }
+ spin_unlock_irq(child-sighand-siglock);
+ }
+ read_unlock(tasklist_lock);
+ if (!error)
+ return copy_siginfo_to_user32(data, lastinfo);
+ return error;
+}
+
long compat_arch_ptrace(struct task_struct *child, compat_long_t request,
compat_ulong_t caddr, compat_ulong_t cdata)
{
@@ -282,6 +306,9 @@ long compat_arch_ptrace(struct task_stru
0, PT_REGS_COUNT * sizeof(compat_long_t),
compat_ptr(data));
+ case PTRACE_GETSIGINFO:
+ return compat_ptrace_getsiginfo(child, compat_ptr(data));
+
case PTRACE_GETFPREGS:
case PTRACE_SETFPREGS:
case PTRACE_GETVRREGS:
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
On Sat, Apr 19, 2008 at 9:30 AM, Kumar Gala [EMAIL PROTECTED] wrote: This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. LITE520052xx This is in arch/powerpc XILINX_ML30040x XILINX_ML40340x These are also supported in arch/powerpc; we just don't have .dts files for the reference designs merged yet. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] rtc-pcf8563: Add device ids table
Jean Delvare wrote: On Sat, 19 Apr 2008 15:09:55 +0200, Jochen Friedrich wrote: Hi Jean, Is the new-style driver conversion patch in 2.6.25-rc8-mm2 scheduled for 2.6.26 ? hope so! :) Note that this patch depends on i2c patches which aren't upstream yet. Is there any chance they will got to 2.6.26? I'm not sure. I didn't have the time to look at it myself, but I am under the impression that the powerpc folks are tired of having to wait for me and may push it to Linus through their tree? That would be fine with me, as I don't want to be the one delaying something many developers want (but I also can't sign patches I've not even read.) The required patches are: http://patchwork.ozlabs.org/linuxppc/patch?id=17833 http://patchwork.ozlabs.org/linuxppc/patch?id=17834 which are just the forward ported patches you sent to the poweprc mailing list some time ago: http://patchwork.ozlabs.org/linuxppc/patch?id=16282 http://patchwork.ozlabs.org/linuxppc/patch?id=16283 Thanks, Jochen ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
On Sat, 2008-04-19 at 10:30 -0500, Kumar Gala wrote: This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. snip OCOTEA 44x I have one of these. I'll port it eventually. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] mpc5200: Switch mpc5200 dts files to dts-v1 format
I wholeheartedly agree, although the difference between gpt and timer and pic vs interrupt-controller (actually interrupt-controller is meant to be a property of the interrupt controller, not a device type.. weird) was chosen because they did not conflict with what might be considered standard device_types with real OF (Forth, CIS) interfaces like read, write, ping, world-peace etc. However since Linux doesn't care about the interface provided by the firmware and only reads the tree, and real OF interfaces MIGHT need to be provided by these items on real OF firmwares, I don't see why they should not be used. A problem arises; how do you decide when you name something after what it is rather than the documentation acronym? What does the 5200B CDM turn into? The XLB arbiter module? What about the rest of the SIU? There really needs to be a standards committee for this, that has good experience with device trees and BSPs, and can work with the device vendors and board manufacturers (Freescale for example) directly, with them on the committee, who can give the docs a run though before any board ever hits the streets... -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Robert Schwebel wrote: On Fri, Apr 18, 2008 at 09:10:04AM -0700, Grant Likely wrote: Update dts files to current format Is it somehow possible that this device tree stuff is *not* changed over and over again and break everything out there? When people have not even agreed on basic things like decimal vs. hex numbers, the whole idea should be developed out-of-tree, then stabilize and *then* be submitted to the Linux mainline. Is it also really necessary to change like gpt vs. timer and pic vs. interrupt-controller all the time? If you compare the last mainline kernels, each one got a fundamental change in the naming, each time breaking anyone who doesn't have his stuff in the mainline yet. Sorry, but this is simply annoying, and the whole the only thing we have to do is to define it once and be done then is crap. Robert ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: removal of arch/ppc in 2.6.27?
This is intended as a reminder that we plan on getting rid of arch/ppc this summer. I'm guessing based on kernel release times that will be 2.6.27. That would mean 2.6.26 will be the last kernel to support arch/ppc. If people have boards that like ported over please let us know and work with us to port this over to arch/powerpc. Here is a list based on arch/ppc/platforms. Its not intended to be complete but a general idea of what's left in arch/ppc. It would be nice to see the mbx860 get forward-ported. I just have not had any time to get to it. Chuck ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc copy_siginfo_from_user32
Hi. I posted this before, but I don't see it in any of your powerpc.git
trees. Can you push this upstream ASAP? It would make life easier for me
trying to merge some more generic changes (that would break powerpc builds
without this going in first).
Thanks,
Roland
---
[PATCH] powerpc copy_siginfo_from_user32
Define the copy_siginfo_from_user32 entry point for powerpc, so
that generic CONFIG_COMPAT code can call it. We already had the
code rolled into compat_sys_rt_sigqueueinfo, this just moves it
out into the canonical function that other arch's define.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
arch/powerpc/kernel/signal_32.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
index d840bc7..ad69434 100644
--- a/arch/powerpc/kernel/signal_32.c
+++ b/arch/powerpc/kernel/signal_32.c
@@ -621,6 +621,18 @@ int copy_siginfo_to_user32(struct compat_siginfo __user
*d, siginfo_t *s)
#define copy_siginfo_to_user copy_siginfo_to_user32
+int copy_siginfo_from_user32(siginfo_t *to, struct compat_siginfo __user *from)
+{
+ memset(to, 0, sizeof *to);
+
+ if (copy_from_user(to, from, 3*sizeof(int)) ||
+ copy_from_user(to-_sifields._pad,
+ from-_sifields._pad, SI_PAD_SIZE32))
+ return -EFAULT;
+
+ return 0;
+}
+
/*
* Note: it is necessary to treat pid and sig as unsigned ints, with the
* corresponding cast to a signed int to insure that the proper conversion
@@ -634,9 +646,10 @@ long compat_sys_rt_sigqueueinfo(u32 pid, u32 sig,
compat_siginfo_t __user *uinfo
int ret;
mm_segment_t old_fs = get_fs();
- if (copy_from_user (info, uinfo, 3*sizeof(int)) ||
- copy_from_user (info._sifields._pad, uinfo-_sifields._pad,
SI_PAD_SIZE32))
- return -EFAULT;
+ ret = copy_siginfo_from_user32(info, uinfo);
+ if (unlikely(ret))
+ return ret;
+
set_fs (KERNEL_DS);
/* The __user pointer cast is valid becasuse of the set_fs() */
ret = sys_rt_sigqueueinfo((int)pid, (int)sig, (siginfo_t __user *)
info);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
