* Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4
From: Paul Mackerras @ 2007-07-10 8:01 UTC (permalink / raw)
To: Jens Axboe
Cc: James E.J. Bottomley, linux-scsi, Alessandro Rubini, linux-kernel,
linuxppc-dev, Geert Uytterhoeven
In-Reply-To: <20070710075506.GS13902@kernel.dk>
Jens Axboe writes:
> I have no objections to the block bits, however I feel uneasy merging
> the full patchset unless patch #1 has been acked by the platform person.
I have the first 3 patches in my queue, so yes I've acked it. It's
probably easiest if the remaining 3 go through my queue once they've
been acked - or if you prefer, you can push #4 via your tree once I've
got Linus to pull my tree. Let me know either way.
Paul.
^ permalink raw reply
* Re: 2.4/2.6/ppc/powerpc/8245/8347e
From: Marc Leeman @ 2007-07-10 7:55 UTC (permalink / raw)
To: Linas Vepstas; +Cc: linuxppc-dev
In-Reply-To: <20070709195623.GK4457@austin.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1539 bytes --]
> > I was expecting a lower DMM performance but wasn't expecting such a
> > drain on kernel/network load.
>
> OK, to be clear: you seem to be saying that using the SLOB instead
> of the SLAB allocator results in such terrible memory fragmentation
> that network performance is degraded by large factors (2x or 5x or
> something like that, if I remember your earlier emails). Is that right?
Yep, I thought I would at least post my findings after hurracing the
list with my posts.
Well, I don't really know if it is the fragmentation that comes into
play, or if it is simply the implementation of the slob allocator that
much more inefficient in allocating free blocks of memory; but that's
about right.
> I thought I heard about some memory-defrag patches being posted.
> What happens if these are used together with SLOB? Does one regain the
> lost performance? Perhaps maybe one gets even better performance?
In the ChangeLog of the 2.6.22, I saw something about a slub allocator
that I want to test; I'll give your suggestion a go too, though I would
not expect significant improvements: I suspect it's the slob
implementation that is slower.
But I had a small problem with my flash not being detected anymore when
quickly booting the 2.6.22, I'll look into it today, there was a note in
the ChangeLog for powerpc about this IIRC.
--
greetz, marc
Better wed than dead.
Crichton - Look at the Princess - A Kiss is Just a Kiss
chiana 2.6.18-4-ixp4xx #1 Tue Mar 27 18:01:56 BST 2007 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [patch 0/6] PS3 Storage Drivers for 2.6.23, take 4
From: Geert Uytterhoeven @ 2007-07-10 7:45 UTC (permalink / raw)
To: Paul Mackerras, Jens Axboe, James E.J. Bottomley,
Alessandro Rubini
Cc: linuxppc-dev, linux-kernel, linux-scsi
In-Reply-To: <20070704132212.726923000@pademelon.sonytel.be>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1646 bytes --]
On Wed, 4 Jul 2007, Geert Uytterhoeven wrote:
> This is the fourth submission of the new PS3 storage drivers:
> [1] ps3: Preallocate bootmem memory for the PS3 FLASH ROM storage driver
> [2] ps3: Storage Driver Core
> [3] ps3: Storage device registration routines.
> [4] ps3: Disk Storage Driver
> [5] ps3: BD/DVD/CD-ROM Storage Driver
> [6] ps3: FLASH ROM Storage Driver
>
> They are based on:
> - the current Linux kernel source tree,
> - plus the PS3 patches already submitted by Geoff Levand on linuxppc-dev,
> - plus the shost_priv() patch in scsi-misc (commit
> bcd92c9fbcc679ee95003083056f0441a1f474fa).
>
> All issues raised during the previous review rounds should be fixed.
> There were no more comments after the third submission.
>
> Paul already integrated Geoff Levand's PS3 patches and the first 3 patches
> in this series in the for-2.6.23 branch in powerpc.git.
>
> Maintainers of block/SCSI/misc, can you please ack the last 3 patches so Paul
> can take them, too?
Ping block/SCSI/misc maintainers?
With kind regards,
Geert Uytterhoeven
Software Architect
Sony Network and Software Technology Center Europe
The Corporate Village · Da Vincilaan 7-D1 · B-1935 Zaventem · Belgium
Phone: +32 (0)2 700 8453
Fax: +32 (0)2 700 8622
E-mail: Geert.Uytterhoeven@sonycom.com
Internet: http://www.sony-europe.com/
Sony Network and Software Technology Center Europe
A division of Sony Service Centre (Europe) N.V.
Registered office: Technologielaan 7 · B-1840 Londerzeel · Belgium
VAT BE 0413.825.160 · RPR Brussels
Fortis Bank Zaventem · Swift GEBABEBB08A · IBAN BE39001382358619
^ permalink raw reply
* [PATCH] powerpc: Fix typo in Ebony default dts
From: Li Yang @ 2007-07-10 6:59 UTC (permalink / raw)
To: Paul; +Cc: linuxppc-dev Development
Signed-off-by: Li Yang <leoli@freescale.com>
---
diff --git a/arch/powerpc/boot/dts/ebony.dts b/arch/powerpc/boot/dts/ebony.dts
index 0ec02f4..59bbae2 100644
--- a/arch/powerpc/boot/dts/ebony.dts
+++ b/arch/powerpc/boot/dts/ebony.dts
@@ -31,8 +31,8 @@
reg = <0>;
clock-frequency = <0>; // Filled in by zImage
timebase-frequency = <0>; // Filled in by zImage
- i-cache-line-size = <32>;
- d-cache-line-size = <32>;
+ i-cache-line-size = <20>;
+ d-cache-line-size = <20>;
i-cache-size = <8000>; /* 32 kB */
d-cache-size = <8000>; /* 32 kB */
dcr-controller;
^ permalink raw reply related
* [kernel-2.6.19]Marvell GT-64260 and Ethernet
From: ThomasB @ 2007-07-10 6:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 446 bytes --]
Hi all,
I'm porting a Linux kernel 2.6.19 on a PowerPC 750 FX board.
My Linux runs completely except for Ethernet. I don't find any Ethernet
driver for my bridge. Do you know if there is an Ethernet driver for the
Marvell GT-64260 bridge for PowerPC processor. I found a GT-64260 ethernet
driver in the kernel 2.4.34 for MIPS processor, will it be possible to port
it in a 2.6 kernel?
Thanks for you help.
--
ThomasB
http://psyphi.zeblog.com/
[-- Attachment #2: Type: text/html, Size: 604 bytes --]
^ permalink raw reply
* [PATCH] Fix the PCI-Ex link training bug on MPC8641HPCN board.
From: Zhang Wei @ 2007-07-10 6:34 UTC (permalink / raw)
To: paulus, galak; +Cc: linuxppc-dev
If the PCI-Ex hose link training is failed, the kernel will halt at the
PCI scan process on MPC8641HPCN board.
This patch will remove and free the hose from PCI host list if the
PCI hose link training is failed.
Signed-off-by: Zhang Wei <wei.zhang@freescale.com>
---
arch/powerpc/platforms/86xx/pci.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/platforms/86xx/pci.c b/arch/powerpc/platforms/86xx/pci.c
index 73cd5b0..0b7835c 100644
--- a/arch/powerpc/platforms/86xx/pci.c
+++ b/arch/powerpc/platforms/86xx/pci.c
@@ -210,8 +210,10 @@ int __init mpc86xx_add_bridge(struct device_node *dev)
/* Probe the hose link training status */
early_read_config_word(hose, 0, 0, PCIE_LTSSM, &val);
- if (val < PCIE_LTSSM_L0)
+ if (val < PCIE_LTSSM_L0) {
+ pcibios_free_controller(hose);
return -ENXIO;
+ }
/* Setup the PCIE host controller. */
mpc86xx_setup_pcie(hose, rsrc.start, rsrc.end - rsrc.start + 1);
--
1.5.1
^ permalink raw reply related
* Re: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
From: Grant Likely @ 2007-07-10 6:22 UTC (permalink / raw)
To: Domen Puncer; +Cc: khali, i2c, linuxppc-embedded
In-Reply-To: <20070710061736.GG4186@moe.telargo.com>
On 7/10/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> On 09/07/07 09:53 -0600, Grant Likely wrote:
> > On 7/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> > >Work around a problem reported on:
> > >http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> > >Without this patch I2C on mpc5200 becomes unusable after a while.
> > >Tested on mpc5200 based boards by Matthias and me.
> > >
> > >Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > >===================================================================
> > >--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> > >+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> > >@@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
> > > static void mpc_i2c_stop(struct mpc_i2c *i2c)
> > > {
> > > writeccr(i2c, CCR_MEN);
> > >+ mb();
> > >+ writeccr(i2c, 0);
> > >+ mb();
> > > }
> >
> > Are the mb() calls necessary? The writeccr path includes eieio; is
> > that not sufficient?
>
> Right, v2:
>
>
> Work around a problem reported on:
> http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> Without this patch I2C on mpc5200 becomes unusable after a while.
> Tested on mpc5200 boards by Matthias and me.
>
>
> Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
Looks good to me,
Acked-by: Grant Likely <grant.likely@secretlab.ca>
>
> ---
> drivers/i2c/busses/i2c-mpc.c | 17 +++++++++++++++++
> 1 file changed, 17 insertions(+)
>
> Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> ===================================================================
> --- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> +++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> @@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq,
> return IRQ_HANDLED;
> }
>
> +static void mpc_i2c_fixup(struct mpc_i2c *i2c)
> +{
> + writeccr(i2c, 0);
> + udelay(30);
> + writeccr(i2c, CCR_MEN);
> + udelay(30);
> + writeccr(i2c, CCR_MSTA | CCR_MTX);
> + udelay(30);
> + writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
> + udelay(30);
> + writeccr(i2c, CCR_MEN);
> + udelay(30);
> +}
> +
> static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
> {
> unsigned long orig_jiffies = jiffies;
> @@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
> static void mpc_i2c_stop(struct mpc_i2c *i2c)
> {
> writeccr(i2c, CCR_MEN);
> + writeccr(i2c, 0);
> }
>
> static int mpc_write(struct mpc_i2c *i2c, int target,
> @@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
> }
> if (time_after(jiffies, orig_jiffies + HZ)) {
> pr_debug("I2C: timeout\n");
> + if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
> + mpc_i2c_fixup(i2c);
> return -EIO;
> }
> schedule();
>
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: [PATCH] i2c-mpc: work around missing-9th-clock-pulse bug
From: Domen Puncer @ 2007-07-10 6:17 UTC (permalink / raw)
To: Grant Likely; +Cc: khali, i2c, linuxppc-embedded
In-Reply-To: <fa686aa40707090853j6079b0c7rbcff7c449baa15e0@mail.gmail.com>
On 09/07/07 09:53 -0600, Grant Likely wrote:
> On 7/9/07, Domen Puncer <domen.puncer@telargo.com> wrote:
> >Work around a problem reported on:
> >http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
> >Without this patch I2C on mpc5200 becomes unusable after a while.
> >Tested on mpc5200 based boards by Matthias and me.
> >
> >Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> >===================================================================
> >--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
> >+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
> >@@ -153,6 +167,9 @@ static void mpc_i2c_start(struct mpc_i2c
> > static void mpc_i2c_stop(struct mpc_i2c *i2c)
> > {
> > writeccr(i2c, CCR_MEN);
> >+ mb();
> >+ writeccr(i2c, 0);
> >+ mb();
> > }
>
> Are the mb() calls necessary? The writeccr path includes eieio; is
> that not sufficient?
Right, v2:
Work around a problem reported on:
http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019038.html
Without this patch I2C on mpc5200 becomes unusable after a while.
Tested on mpc5200 boards by Matthias and me.
Signed-off-by: Domen Puncer <domen.puncer@telargo.com>
---
drivers/i2c/busses/i2c-mpc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
Index: work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
===================================================================
--- work-powerpc.git.orig/drivers/i2c/busses/i2c-mpc.c
+++ work-powerpc.git/drivers/i2c/busses/i2c-mpc.c
@@ -74,6 +74,20 @@ static irqreturn_t mpc_i2c_isr(int irq,
return IRQ_HANDLED;
}
+static void mpc_i2c_fixup(struct mpc_i2c *i2c)
+{
+ writeccr(i2c, 0);
+ udelay(30);
+ writeccr(i2c, CCR_MEN);
+ udelay(30);
+ writeccr(i2c, CCR_MSTA | CCR_MTX);
+ udelay(30);
+ writeccr(i2c, CCR_MSTA | CCR_MTX | CCR_MEN);
+ udelay(30);
+ writeccr(i2c, CCR_MEN);
+ udelay(30);
+}
+
static int i2c_wait(struct mpc_i2c *i2c, unsigned timeout, int writing)
{
unsigned long orig_jiffies = jiffies;
@@ -153,6 +167,7 @@ static void mpc_i2c_start(struct mpc_i2c
static void mpc_i2c_stop(struct mpc_i2c *i2c)
{
writeccr(i2c, CCR_MEN);
+ writeccr(i2c, 0);
}
static int mpc_write(struct mpc_i2c *i2c, int target,
@@ -245,6 +260,8 @@ static int mpc_xfer(struct i2c_adapter *
}
if (time_after(jiffies, orig_jiffies + HZ)) {
pr_debug("I2C: timeout\n");
+ if (readb(i2c->base + MPC_I2C_SR) == (CSR_MCF | CSR_MBB | CSR_RXAK))
+ mpc_i2c_fixup(i2c);
return -EIO;
}
schedule();
^ permalink raw reply
* Please pull from 'for_paulus' branch
From: Kumar Gala @ 2007-07-10 5:42 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus
to receive the following updates:
Documentation/powerpc/booting-without-of.txt | 32 ++
arch/powerpc/boot/dts/mpc8272ads.dts | 42 +--
arch/powerpc/boot/dts/mpc832x_mds.dts | 16 +
arch/powerpc/boot/dts/mpc832x_rdb.dts | 16 +
arch/powerpc/boot/dts/mpc8349emitx.dts | 10
arch/powerpc/boot/dts/mpc834x_mds.dts | 10
arch/powerpc/boot/dts/mpc836x_mds.dts | 16 +
arch/powerpc/boot/dts/mpc8540ads.dts | 147 ++++++-----
arch/powerpc/boot/dts/mpc8541cds.dts | 90 +++---
arch/powerpc/boot/dts/mpc8544ds.dts | 18 -
arch/powerpc/boot/dts/mpc8548cds.dts | 108 ++++----
arch/powerpc/boot/dts/mpc8555cds.dts | 90 +++---
arch/powerpc/boot/dts/mpc8560ads.dts | 148 ++++++-----
arch/powerpc/boot/dts/mpc8568mds.dts | 66 +++--
arch/powerpc/boot/dts/mpc8641_hpcn.dts | 50 ++-
arch/powerpc/boot/dts/mpc866ads.dts | 31 --
arch/powerpc/boot/dts/mpc885ads.dts | 54 ++--
arch/powerpc/kernel/io.c | 12
arch/powerpc/kernel/pci_32.c | 34 --
arch/powerpc/kernel/pci_64.c | 9
arch/powerpc/mm/hash_native_64.c | 2
arch/powerpc/mm/stab.c | 4
arch/powerpc/platforms/52xx/efika.c | 4
arch/powerpc/platforms/52xx/lite5200.c | 2
arch/powerpc/platforms/52xx/mpc52xx_pm.c | 8
arch/powerpc/platforms/83xx/Makefile | 2
arch/powerpc/platforms/83xx/mpc8313_rdb.c | 1
arch/powerpc/platforms/83xx/mpc834x_itx.c | 2
arch/powerpc/platforms/83xx/mpc834x_mds.c | 49 ---
arch/powerpc/platforms/83xx/mpc83xx.h | 28 +-
arch/powerpc/platforms/83xx/usb.c | 181 +++++++++++++
arch/powerpc/platforms/85xx/misc.c | 32 ++
arch/powerpc/platforms/85xx/mpc8544_ds.c | 15 -
arch/powerpc/platforms/85xx/mpc85xx_ads.c | 22 -
arch/powerpc/platforms/85xx/mpc85xx_cds.c | 99 ++-----
arch/powerpc/platforms/85xx/mpc85xx_mds.c | 21 -
arch/powerpc/platforms/86xx/mpc86xx_hpcn.c | 15 -
arch/powerpc/platforms/8xx/m8xx_setup.c | 5
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 71 +++++
arch/powerpc/sysdev/fsl_soc.c | 13 +
arch/powerpc/sysdev/mpc8xx_pic.h | 11
arch/powerpc/sysdev/qe_lib/ucc.c | 2
arch/powerpc/sysdev/qe_lib/ucc_fast.c | 8
arch/ppc/mm/tlb.c | 1
drivers/pcmcia/Kconfig | 17 -
drivers/pcmcia/m8xx_pcmcia.c | 351 ++++++++++++---------------
drivers/serial/cpm_uart/cpm_uart_core.c | 2
include/asm-powerpc/mmu-8xx.h | 147 +++++++++++
include/asm-powerpc/mmu-fsl-booke.h | 88 ++++++
include/asm-powerpc/mmu.h | 10
include/asm-powerpc/mmu_context.h | 202 +++++++++++++++
include/asm-powerpc/mpc8xx.h | 4
include/asm-powerpc/system.h | 2
include/linux/fsl_devices.h | 5
54 files changed, 1591 insertions(+), 834 deletions(-)
David Gibson (2):
[POWERPC] Split out asm-ppc/mmu.h portions for Freescale Book-E
[POWERPC] Split out asm-ppc/mmu.h portions for PowerPC 8xx
Domen Puncer (1):
[POWERPC] 52xx: sparse fixes
Grant Likely (1):
[POWERPC] 83xx: Add USB support to mpc8349-mitx board port
Jon Loeliger (1):
[POWERPC] Replace use of GET_64BIT(prop, i) with of_read_number().
Kumar Gala (6):
[POWERPC] Reworked interrupt numbers for OpenPIC based Freescale chips
[POWERPC] Kill pcibios_enable_resources()
[POWERPC] Fix up interrupt senses for MPC85xx boards
[POWERPC] Merge asm-ppc/mmu_context.h into asm-power/mmu_context.h
[POWERPC] Move inline asm eieio to using eieio inline function
[POWERPC] CPM_UART: Use inline function form of eieio
Laurent Pinchart (1):
[PPC] Add linux/pagemap.h to arch/ppc/mm/tlb.c
Li Yang (2):
[POWERPC] qe_lib: export symbols for QE driver to compile as module
[POWERPC] 83xx: USB platform code rework
Roy Zang (4):
[POWERPC] Document the global utilities node define and example
[POWERPC] Fix the node index confusion for SOC
[POWERPC] 85xx: Fix 8548CDS reset bug
[POWERPC] Remove redundant pci_read_irq_line() function for 85xx platform
Timur Tabi (1):
[POWERPC] Fix MAC address entries for 83xx, 85xx, and 86xx device trees
Vitaly Bordug (2):
[POWERPC] 8xx: mpc885ads pcmcia support
[POWERPC] dts: kill hardcoded phandles
^ permalink raw reply
* [PATCH] ide: Use inline function for eieio
From: Kumar Gala @ 2007-07-10 5:23 UTC (permalink / raw)
To: bzolnier; +Cc: linux-ide, linuxppc-dev
Move to using inline function variant of eieio instead of inline assmebly.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
commit ff6ce6329e19cb82ee12447fe16c76c3dae7c1f4
tree ef830cd02624a79d7fa8c33b41f7229ff25a7d77
parent b30083183bf4987c8f7e9a8f753002a7ca5dc084
author Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jul 2007 00:13:54 -0500
committer Kumar Gala <galak@kernel.crashing.org> Tue, 10 Jul 2007 00:13:54 -0500
drivers/ide/pci/scc_pata.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/ide/pci/scc_pata.c b/drivers/ide/pci/scc_pata.c
index 55bc0a3..b9fd2ac 100644
--- a/drivers/ide/pci/scc_pata.c
+++ b/drivers/ide/pci/scc_pata.c
@@ -165,9 +165,9 @@ scc_ide_outbsync(ide_drive_t * drive, u8 addr, unsigned long port)
ide_hwif_t *hwif = HWIF(drive);
out_be32((void*)port, addr);
- __asm__ __volatile__("eieio":::"memory");
+ eieio();
in_be32((void*)(hwif->dma_base + 0x01c));
- __asm__ __volatile__("eieio":::"memory");
+ eieio();
}
static void
^ permalink raw reply related
* Re: Patches added to 2.6.23 branch
From: Paul Mackerras @ 2007-07-10 5:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev
In-Reply-To: <20070703141528.GC18565@lst.de>
Christoph Hellwig writes:
> On Tue, Jul 03, 2007 at 03:36:09PM +1000, Paul Mackerras wrote:
> > The following patches have been added to the for-2.6.23 branch on
> > powerpc.git. In addition, the master branch has the merge of the
> > for-2.6.23 and merge branches, which means that it is up-to-date with
> > Linus' 2.6.22-rc7 plus the patches I recently asked Linus to pull for
> > inclusion in 2.6.22.
>
> What happened to Ben's and my signal and ptrace patches?
They are in already; they were in the first lot (see my post to
linuxppc-dev of 15 June, "for-2.6.23 branch in powerpc.git created".
Paul.
^ permalink raw reply
* Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
From: Albert Lee @ 2007-07-10 3:52 UTC (permalink / raw)
To: Mikael Pettersson
Cc: dwm, jeff, linux-ide, bahadir.balban, linuxppc-dev, alan
In-Reply-To: <200707092304.l69N4Ggd023137@harpo.it.uu.se>
Mikael Pettersson wrote:
> (cc:ing linuxppc-dev)
>
> On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
>
>>Recently the PLL input clock of pata_pdc2027x is sometimes detected
>>higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
>>It seems sometimes the mdelay() function is not as precise as it
>>used to be. Per Alan's advice, HT or power management might affect
>>the precision of mdelay().
>>
>>This patch calls gettimeofday() to mesure the time elapsed and
>>calculate the PLL input clock accordingly.
>
>
> Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
>
<snip>
>
> In fairness, this is a slightly non-standard PowerMac G3, in that it
> has a G4 upgrade processor. The firmware doesn't recognise the CPU
> and gives some CPU core frequency-related properties too low values.
> However, the bus frequency property _is_ correct, which is what
> most or all timing stuff should be based on.
>
> Looks like a platform bug.
>
According to the document, do_gettimeofday() has microsecond
resolution. Since the driver calls mdelay(100) (100000 microseconds),
it won't affect the PLL input clock calculation much if somehow
do_gettimeofday() drifts several (say 100) microseconds.
Could you please apply the attached debug patch and collect more info
on the PowerMac G3. Hopefully we can have more clue. Thanks.
--
albert
(BTW, maybe opening a bug in bugzilla.kernel.org would help the
debugging.)
--- 00_libata-dev/drivers/ata/pata_pdc2027x.c 2007-07-07 09:58:55.000000000 +0800
+++ 01_debug/drivers/ata/pata_pdc2027x.c 2007-07-10 11:18:38.000000000 +0800
@@ -722,6 +722,15 @@ static long pdc_detect_pll_input_clock(s
pll_clock = (start_count - end_count) / 100 *
(100000000 / usec_elapsed);
+ do_gettimeofday(&start_time);
+ mdelay(37);
+ do_gettimeofday(&end_time);
+ usec_elapsed = (end_time.tv_sec - start_time.tv_sec) * 1000000 +
+ (end_time.tv_usec - start_time.tv_usec);
+ printk(KERN_ERR "usec_elapsed for mdelay(37) [%ld]\n", usec_elapsed);
+ printk(KERN_ERR "start time: [%ld]s [%ld]us \n", start_time.tv_sec, start_time.tv_usec);
+ printk(KERN_ERR "end time: [%ld]s [%ld]us \n", end_time.tv_sec, end_time.tv_usec);
+
PDPRINTK("start[%ld] end[%ld] \n", start_count, end_count);
PDPRINTK("PLL input clock[%ld]Hz\n", pll_clock);
^ permalink raw reply
* Re: [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Paul Mackerras @ 2007-07-10 3:01 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc-dev
In-Reply-To: <20070709214853.GA29912@ld0162-tx32.am.freescale.net>
Scott Wood writes:
> In older versions of glibc (through 2.3), the dynamic linker executes a
> small amount of code from the data segment, which is not marked as
> executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
> stops this from working; there should be a deprecation period before
> older glibc versions stop working.
Actually I see no good reason to enforce no-exec at all if we can't do
it consistently. And if we're not going to enforce it then there is
no point whinging about it.
When I applied Segher's original patch I thought that we had the
read-implies-exec stuff enabled for the affected CPUs, but it turns
out we don't. (We only have that stuff turned on for 32-bit processes
on 64-bit cpus - see elf_read_implies_exec in include/asm-powerpc/elf.h.)
Paul.
^ permalink raw reply
* A question about _PAGE_PRESENT flag when ioremap is executed....
From: kang shuo @ 2007-07-10 2:11 UTC (permalink / raw)
To: linuxppc-embedded
hi:
I had read some confusing code about io address map in
MPC8560 that employs E500 core. My confusion is when io address map is
setup, if _PAGE_PRESENT flag of page is set? In implementation of
mpc8560 , that seems page flag that maps to io address region is
0x280, means only the following flag is set:
#define _PAGE_GUARDED 0x00080 /* H: G bit */
#define _PAGE_NO_CACHE 0x00200 /* H: I bit */
But I think _PAGE_PRESENT shoulbe be set for BOOKE too...
/* Definitions for FSL Book-E Cores */
#define _PAGE_PRESENT 0x00001 /* S: PTE contains a translation */
Any guys give me some idea about that? Thanks....
-- Michael.Kang
^ permalink raw reply
* Re: [PATCH] Infinite loop/always true check possible with unsigned counter.
From: Felix Domke @ 2007-07-10 0:41 UTC (permalink / raw)
To: ppc-dev
In-Reply-To: <18066.53384.449544.952545@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
>> Fix to correct a possible infinite loop or an always true check when the
>> unsigned long counter "i" is used in
>> lmb_add_region() in the following for loop:
>> for (i = rgn->cnt-1; i >= 0; i--)
> Unfortunately this won't fix the bug. Since rgn->cnt is unsigned
> long, the comparison will be done as an unsigned comparison even if i
> is signed.
> Instead, change the loop to go from rgn->cnt down to 1, and in the
> loop body, change all instances of "i+1" to "i", and "i" to "i-1".
What's about
i = rgn->cnt;
while (i--)
...
?
(or for (i=rgn->cnt; i--; ), if you want a for-loop)
Felix
^ permalink raw reply
* Re: [PATCH] Infinite loop/always true check possible with unsigned counter.
From: Paul Mackerras @ 2007-07-10 0:19 UTC (permalink / raw)
To: Manish Ahuja; +Cc: ppc-dev
In-Reply-To: <46928691.2040008@austin.ibm.com>
Manish Ahuja writes:
> Repost to fix my email id.
>
> Fix to correct a possible infinite loop or an always true check when the
> unsigned long counter "i" is used in
> lmb_add_region() in the following for loop:
>
> for (i = rgn->cnt-1; i >= 0; i--)
Unfortunately this won't fix the bug. Since rgn->cnt is unsigned
long, the comparison will be done as an unsigned comparison even if i
is signed.
Instead, change the loop to go from rgn->cnt down to 1, and in the
loop body, change all instances of "i+1" to "i", and "i" to "i-1".
Paul.
^ permalink raw reply
* [2.6 patch] drivers/video/macmodes.c:mac_find_mode() mustn't be __devinit
From: Adrian Bunk @ 2007-07-10 0:19 UTC (permalink / raw)
To: Mikael Pettersson, adaplas
Cc: linuxppc-dev, Andrew Morton, linux-kernel, stable
In-Reply-To: <200707092347.l69NlElB023451@harpo.it.uu.se>
On Tue, Jul 10, 2007 at 01:47:14AM +0200, Mikael Pettersson wrote:
> A vanilla 2.6.22 built for ppc32 and configured with CONFIG_FB_MACMODES=y, CONFIG_HOTPLUG=n,
> and CONFIG_MODULES=y, triggers the following warning from modpost:
>
> WARNING: drivers/built-in.o(__ksymtab+0x3b0): Section mismatch: reference to .init.text:mac_find_mode (between '__ksymtab_mac_find_mode' and '__ksymtab_mac_map_monitor_sense')
>
> There's an EXPORT_SYMBOL(mac_find_mode), but mac_find_mode() is __devinit
> and thus __init in this kernel.
So let's fix it. ;-)
> /Mikael
cu
Adrian
<-- snip -->
If it's EXPORT_SYMBOL'ed it can't be __devinit.
Reported by Mikael Pettersson.
Signed-off-by: Adrian Bunk <bunk@stusta.de>
---
@stable:
Fixes a real bug on ppc.
drivers/video/macmodes.c | 5 ++---
drivers/video/macmodes.h | 8 ++++----
2 files changed, 6 insertions(+), 7 deletions(-)
--- linux-2.6.22-rc6-mm1/drivers/video/macmodes.h.old 2007-07-10 01:55:14.000000000 +0200
+++ linux-2.6.22-rc6-mm1/drivers/video/macmodes.h 2007-07-10 01:55:29.000000000 +0200
@@ -55,10 +55,10 @@
extern int mac_var_to_vmode(const struct fb_var_screeninfo *var, int *vmode,
int *cmode);
extern int mac_map_monitor_sense(int sense);
-extern int __devinit mac_find_mode(struct fb_var_screeninfo *var,
- struct fb_info *info,
- const char *mode_option,
- unsigned int default_bpp);
+extern int mac_find_mode(struct fb_var_screeninfo *var,
+ struct fb_info *info,
+ const char *mode_option,
+ unsigned int default_bpp);
/*
--- linux-2.6.22-rc6-mm1/drivers/video/macmodes.c.old 2007-07-10 01:54:36.000000000 +0200
+++ linux-2.6.22-rc6-mm1/drivers/video/macmodes.c 2007-07-10 01:55:04.000000000 +0200
@@ -369,9 +369,8 @@
*
*/
-int __devinit mac_find_mode(struct fb_var_screeninfo *var,
- struct fb_info *info, const char *mode_option,
- unsigned int default_bpp)
+int mac_find_mode(struct fb_var_screeninfo *var, struct fb_info *info,
+ const char *mode_option, unsigned int default_bpp)
{
const struct fb_videomode *db = NULL;
unsigned int dbsize = 0;
^ permalink raw reply
* [PATCH] xilinxfb: Parameterize xilinxfb platform device registration
From: Grant Likely @ 2007-07-09 23:51 UTC (permalink / raw)
To: linuxppc-dev, paulus
From: Grant Likely <grant.likely@secretlab.ca>
This patch allows multiple xilinxfb devices to be registered and used
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
cc: Andrei Konovalov <akonovalov@ru.mvista.com>
---
arch/ppc/syslib/virtex_devices.c | 38 +++++++++++++++++++++++++-------------
1 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/ppc/syslib/virtex_devices.c b/arch/ppc/syslib/virtex_devices.c
index 83f978f..9b473cf 100644
--- a/arch/ppc/syslib/virtex_devices.c
+++ b/arch/ppc/syslib/virtex_devices.c
@@ -152,6 +152,21 @@
}, \
}
+/*
+ * ML300/ML403 Video Device: shortcut macro for single instance
+ */
+#define XPAR_TFT(num) { \
+ .name = "xilinxfb", \
+ .id = num, \
+ .num_resources = 1, \
+ .resource = (struct resource[]) { \
+ { \
+ .start = XPAR_TFT_##num##_BASEADDR, \
+ .end = XPAR_TFT_##num##_BASEADDR+7, \
+ .flags = IORESOURCE_IO, \
+ }, \
+ }, \
+}
/* UART 8250 driver platform data table */
struct plat_serial8250_port virtex_serial_platform_data[] = {
@@ -274,20 +289,17 @@ struct platform_device virtex_platform_devices[] = {
#endif
#endif
- /* ML300/403 reference design framebuffer */
#if defined(XPAR_TFT_0_BASEADDR)
- {
- .name = "xilinxfb",
- .id = 0,
- .num_resources = 1,
- .resource = (struct resource[]) {
- {
- .start = XPAR_TFT_0_BASEADDR,
- .end = XPAR_TFT_0_BASEADDR+7,
- .flags = IORESOURCE_IO,
- },
- },
- },
+ XPAR_TFT(0),
+#endif
+#if defined(XPAR_TFT_1_BASEADDR)
+ XPAR_TFT(1),
+#endif
+#if defined(XPAR_TFT_2_BASEADDR)
+ XPAR_TFT(2),
+#endif
+#if defined(XPAR_TFT_3_BASEADDR)
+ XPAR_TFT(3),
#endif
};
^ permalink raw reply related
* [2.6.22] powerpc: section mismatch for macmodes.c:mac_find_mode()
From: Mikael Pettersson @ 2007-07-09 23:47 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-kernel
A vanilla 2.6.22 built for ppc32 and configured with CONFIG_FB_MACMODES=y, CONFIG_HOTPLUG=n,
and CONFIG_MODULES=y, triggers the following warning from modpost:
WARNING: drivers/built-in.o(__ksymtab+0x3b0): Section mismatch: reference to .init.text:mac_find_mode (between '__ksymtab_mac_find_mode' and '__ksymtab_mac_map_monitor_sense')
There's an EXPORT_SYMBOL(mac_find_mode), but mac_find_mode() is __devinit
and thus __init in this kernel.
/Mikael
^ permalink raw reply
* Re: [PATCH] Add USB support to mpc8349-mitx board port
From: John Rigby @ 2007-07-09 23:35 UTC (permalink / raw)
To: Grant Likely; +Cc: Linuxppc-embedded
In-Reply-To: <fa686aa40707091003n45870ccdn8c9a3629cf19cf77@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 920 bytes --]
I'm just saying that an argument can be made that having all the OF to
non-OF
glue in one place is better than having dual bindings in every driver.
If you count ugliness in terms of file count the fsl_soc.c solution
gets a score of 1 and the dual binding solution gets an score of N.
Where N is the number of drivers.
John
On 7/9/07, Grant Likely <grant.likely@secretlab.ca> wrote:
>
> On 7/8/07, John Rigby <jcrigby@gmail.com> wrote:
> > I see your point, I agree the two layers of glue is bad. But this means
> > the double code is spread across many drivers instead of being in one
> > place (fsl_soc.c).
>
> ??? I don't understand what you mean. Are you saying that it's
> better to have all the OF bindings in one place (fsl_soc.c) instead of
> with each individual driver?
>
> Cheers,
> g.
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
>
[-- Attachment #2: Type: text/html, Size: 1388 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] libata: pata_pdc2027x PLL input clock fix
From: Mikael Pettersson @ 2007-07-09 23:04 UTC (permalink / raw)
To: albertl, jeff; +Cc: dwm, mikpe, linux-ide, bahadir.balban, linuxppc-dev, alan
(cc:ing linuxppc-dev)
On Tue, 26 Jun 2007 13:43:15 +0800, Albert Lee wrote:
> Recently the PLL input clock of pata_pdc2027x is sometimes detected
> higer than expected (e.g. 20.027 MHz compared to 16.714 MHz).
> It seems sometimes the mdelay() function is not as precise as it
> used to be. Per Alan's advice, HT or power management might affect
> the precision of mdelay().
>
> This patch calls gettimeofday() to mesure the time elapsed and
> calculate the PLL input clock accordingly.
Unfortunately this breaks pata_pdc2027x on my PowerMac G3:
--- dmesg-2.6.22-rc5 2007-06-23 20:45:45.000000000 +0200
+++ dmesg-2.6.22 2007-07-10 00:39:51.000000000 +0200
@@ -1,6 +1,6 @@
Using PowerMac machine description
Total memory = 768MB; using 2048kB for hash table (at cfe00000)
-Linux version 2.6.22-rc5 (mikpe@eisbock) (gcc version 4.2.0) #1 Sat Jun 23 20:38:48 CEST 2007
+Linux version 2.6.22 (mikpe@eisbock) (gcc version 4.2.0) #1 Tue Jul 10 00:29:58 CEST 2007
Found a Heathrow mac-io controller, rev: 1, mapped at 0xfdf80000
PowerMac motherboard: PowerMac G3 (Gossamer)
Entering add_active_range(0, 0, 196608) 0 entries of 256 used
@@ -32,7 +32,7 @@
console handover: boot [udbg0] -> real [tty0]
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
-Memory: 771456k/786432k available (2344k kernel code, 14560k reserved, 116k data, 94k bss, 148k init)
+Memory: 771584k/786432k available (2340k kernel code, 14544k reserved, 116k data, 94k bss, 148k init)
Calibrating delay loop... 33.38 BogoMIPS (lpj=166912)
Mount-cache hash table entries: 512
device-tree: Duplicate name in /pci/mac-io, renamed to "ide#1"
@@ -108,17 +108,15 @@
sda: [mac] sda1 sda2 sda3 sda4 sda5 sda6 sda7 sda8 sda9
sd 0:0:0:0: [sda] Attached SCSI disk
pata_pdc2027x 0000:00:0e.0: version 0.9
-pata_pdc2027x 0000:00:0e.0: PLL input clock 16000 kHz
+pata_pdc2027x 0000:00:0e.0: PLL input clock 1691742 kHz
+pata_pdc2027x: Invalid PLL input clock 1691742kHz, give up!
scsi1 : pata_pdc2027x
scsi2 : pata_pdc2027x
-ata1: PATA max UDMA/133 cmd 0xf10197c0 ctl 0xf1019fda bmdma 0xf1019000 irq 0
-ata2: PATA max UDMA/133 cmd 0xf10195c0 ctl 0xf1019dda bmdma 0xf1019008 irq 0
-ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480
+ata1: PATA max UDMA/133 cmd 0xf10197c0 ctl 0xf1019fda bmdma 0xf1019000 irq 24
+ata2: PATA max UDMA/133 cmd 0xf10195c0 ctl 0xf1019dda bmdma 0xf1019008 irq 24
ata1.00: ATA-5: IBM-DTLA-307030, TX4OA6AA, max UDMA/100
ata1.00: 60036480 sectors, multi 0: LBA
-ata1.00: ata_hpa_resize 1: sectors = 60036480, hpa_sectors = 60036480
ata1.00: configured for UDMA/100
-ATA: abnormal status 0x8 on port 0xf10195df
scsi 1:0:0:0: Direct-Access ATA IBM-DTLA-307030 TX4O PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] 60036480 512-byte hardware sectors (30739 MB)
sd 1:0:0:0: [sdb] Write Protect is off
@@ -128,7 +126,36 @@
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
- sdb: sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
+ sdb:<3>ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+ res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+ res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+ res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/100
+ata1: EH complete
+ata1.00: limiting speed to UDMA/66:PIO4
+ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2
+ata1.00: (BMDMA stat 0x4)
+ata1.00: cmd c8/00:08:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data 4096 in
+ res 51/84:00:07:00:00/00:00:00:00:00/e0 Emask 0x10 (ATA bus error)
+ata1: soft resetting port
+ata1.00: configured for UDMA/66
+ata1: EH complete
+ sdb1 sdb2 sdb3 sdb4 < sdb5 sdb6 sdb7 >
sd 1:0:0:0: [sdb] Attached SCSI disk
mice: PS/2 mouse device common for all mice
TCP cubic registered
In fairness, this is a slightly non-standard PowerMac G3, in that it
has a G4 upgrade processor. The firmware doesn't recognise the CPU
and gives some CPU core frequency-related properties too low values.
However, the bus frequency property _is_ correct, which is what
most or all timing stuff should be based on.
Looks like a platform bug.
/Mikael
^ permalink raw reply
* Re: [PATCH v2][POWERPC] document ipic level/sense info
From: Grant Likely @ 2007-07-09 22:48 UTC (permalink / raw)
To: Stuart Yoder; +Cc: linuxppc-dev, paulus
In-Reply-To: <200707092235.l69MZRnh015324@ld0164-tx32.am.freescale.net>
On 7/9/07, Stuart Yoder <b08248@freescale.com> wrote:
>
> document level and sense information for the Freescale
> IPIC interrupt controller
>
> +Sense and level information follows the Linux convention
> +(specified in include/linux/interrupt.h) and should be encoded
> +as follows:
> +
> + 2 = high to low edge sensitive type enabled
> + 8 = active low level sensitive type enabled
> +
... but it is probably worthwhile commentting that sense types 1 & 4
are not supported; just to fill in the obvious gaps. :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH v2][POWERPC] document ipic level/sense info
From: Stuart Yoder @ 2007-07-09 22:35 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
document level and sense information for the Freescale
IPIC interrupt controller
Signed-off-by: Stuart Yoder <stuart.yoder@freescale.com>
---
Documentation/powerpc/booting-without-of.txt | 18 +++++++++++++++++-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index c169299..7ad9e42 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -50,13 +50,14 @@ Table of Contents
g) Freescale SOC SEC Security Engines
h) Board Control and Status (BCSR)
i) Freescale QUICC Engine module (QE)
- g) Flash chip nodes
+ j) Flash chip nodes
VII - Specifying interrupt information for devices
1) interrupts property
2) interrupt-parent property
3) OpenPIC Interrupt Controllers
4) ISA Interrupt Controllers
+ 5) IPIC Interrupt Controllers
Appendix A - Sample SOC node for MPC8540
@@ -1878,6 +1879,21 @@ encodings listed below:
2 = high to low edge sensitive type enabled
3 = low to high edge sensitive type enabled
+5) Freescale IPIC Interrupt Controllers
+---------------------------------------
+
+IPIC interrupt controllers are specific to Freescale 83xx
+SOCs. Two cells are required to encode interrupt information.
+The first cell defines the interrupt number. The second cell
+defines the sense and level information.
+
+Sense and level information follows the Linux convention
+(specified in include/linux/interrupt.h) and should be encoded
+as follows:
+
+ 2 = high to low edge sensitive type enabled
+ 8 = active low level sensitive type enabled
+
Appendix A - Sample SOC node for MPC8540
========================================
--
1.5.0.3
^ permalink raw reply related
* Re: [PATCH 00/13] IB/ehca: eHCA2 enablement & some fixes
From: Roland Dreier @ 2007-07-09 22:11 UTC (permalink / raw)
To: Joachim Fenkes
Cc: LKML, LinuxPPC-Dev, Christoph Raisch, OF-General, Stefan Roscher
In-Reply-To: <200707091502.22407.fenkes@de.ibm.com>
thanks, I applied these for 2.6.23 and fixed a bunch of minor things
that scripts/checkpatch.pl complained about (since I was in a mood to
do mindless things). In the future please run that yourself and clean
up the obvious things. I generally don't worry about the 80 column
stuff, but it will catch most whitespace problems and tell you that
foo(x,y) should be foo(x, y) etc. So you don't have to completely
silence the script but at least take a look at the output.
^ permalink raw reply
* [PATCH v2] Allow exec on 32-bit from readable, non-exec pages, with a warning.
From: Scott Wood @ 2007-07-09 21:48 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
In older versions of glibc (through 2.3), the dynamic linker executes a
small amount of code from the data segment, which is not marked as
executable. A recent change (commit 9ba4ace39fdfe22268daca9f28c5df384ae462cf)
stops this from working; there should be a deprecation period before
older glibc versions stop working.
The problem has been observed on glibc 2.2. While glibc 2.3 has the same
code, I did not see the problem; it may be that it accesses the page in
question as data before executing from it, and thus it is already mapped.
Note that this only applies to the classic 32-bit PowerPC MMU and the
MPC8xx MMU, not Book E, 64-bit, etc. These MMUs do not support per-page
no-exec, and thus this patch isn't taking away any effective protection
enforcement. Currently, such accesses will fail only if the page in
question has not already been faulted on (and thus mapped).
Signed-off-by: Scott Wood <scottwood@freescale.com>
---
v2: Added to the changelog to explain why this change isn't harmful.
arch/powerpc/mm/fault.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
index 0ece513..2445512 100644
--- a/arch/powerpc/mm/fault.c
+++ b/arch/powerpc/mm/fault.c
@@ -125,6 +125,18 @@ static void do_dabr(struct pt_regs *regs, unsigned long address,
}
#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
+#ifdef CONFIG_PPC32
+static void warn_exec_from_noexec(void)
+{
+ if (printk_ratelimit())
+ printk(KERN_WARNING "Process %s (%d) attempted to execute from "
+ "a non-executable page.\n"
+ KERN_WARNING "This may stop working in future kernels. "
+ "Please upgrade your libc.\n",
+ current->comm, current->pid);
+}
+#endif
+
/*
* For 600- and 800-family processors, the error_code parameter is DSISR
* for a data fault, SRR1 for an instruction fault. For 400-family processors
@@ -283,8 +295,16 @@ good_area:
/* protection fault */
if (error_code & DSISR_PROTFAULT)
goto bad_area;
- if (!(vma->vm_flags & VM_EXEC))
+ if (!(vma->vm_flags & VM_EXEC)) {
+#ifdef CONFIG_PPC32
+ if (vma->vm_flags & VM_READ)
+ warn_exec_from_noexec();
+ else
+ goto bad_area;
+#else
goto bad_area;
+#endif
+ }
#else
pte_t *ptep;
pmd_t *pmdp;
--
1.5.0.3
^ permalink raw reply related
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