* Re: insmod: unresolved symbol XIo_In32/XIo_Out32
From: Grant Likely @ 2008-07-11 18:31 UTC (permalink / raw)
To: Juliana Su; +Cc: linuxppc-embedded
In-Reply-To: <48776D93.5080504@bucknell.edu>
On Fri, Jul 11, 2008 at 10:26:27AM -0400, Juliana Su wrote:
> Hi,
>
> Is anybody familiar with the following error?
>
> insmod: unresolved symbol XIo_In32
> insmod: unresolved symbol XIo_Out32
>
> I am trying to write a device driver for a Custom IP and get it to run
> on a Xilinx ML310's Linux OS. I am using Xilinx EDK 10.1 and MontaVista
> Linux version 2.4.20_mvl31-ml300. I ran into this error when trying to
> load my module into the kernel. When I try to load the module using
> insmod on the ".o" file, the module refuses to load and gives me the
> unresolved symbol error message. I actually stumbled upon an older
> posting from June 2006 on this mailing list that described a similar
> problem, but those suggestions did not help me. Maybe two years later,
> there are more ideas/suggestions/solutions to this problem?
I can't help much with the 2.4 montavista kernel, but I can say that the
error means that the XIo_* helper routines are either not compiled into
the kernel or are not exported with EXPORT_SYMBOL(). The XIo_* routines
are hooks used by Xilinx cross platform device drivers to make the
actual accesses to hardware. If they are not implemented, then you need
to create them yourself.
g.
^ permalink raw reply
* Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
From: Grant Likely @ 2008-07-11 18:23 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: khali, linuxppc-dev, i2c
In-Reply-To: <20080711174859.GA24260@polina.dev.rtsoft.ru>
On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
> Firstly kernel warns at set_irq_chip, and then dies completely:
>
> Trying to install chip for IRQ-1
>
> diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
> index b2ccdcb..95a24de 100644
> --- a/drivers/of/of_i2c.c
> +++ b/drivers/of/of_i2c.c
> @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
> if (info.irq == NO_IRQ)
> info.irq = -1;
What is the reason that info.irq is set to -1 in the first place? This
looks like another bug to me. Does something in the i2c layer depend on
the -1 value?
g.
^ permalink raw reply
* Re: [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
From: Anton Vorontsov @ 2008-07-11 18:14 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20080711174859.GA24260@polina.dev.rtsoft.ru>
On Fri, Jul 11, 2008 at 09:48:59PM +0400, Anton Vorontsov wrote:
> Firstly kernel warns at set_irq_chip, and then dies completely:
>
> Trying to install chip for IRQ-1
> ------------[ cut here ]------------
> Badness at c00463b0 [verbose debug info unavailable]
[..]
> Unable to handle kernel paging request for data at address 0x3863ce7c
Btw, I'm seeing this on linux-next. Just looked into the current Linus'
tree, and it seems that the bug is there too. So, this is probably should
go for 2.6.26.
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/of/of_i2c.c | 13 +++++++------
> 1 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
> index b2ccdcb..95a24de 100644
> --- a/drivers/of/of_i2c.c
> +++ b/drivers/of/of_i2c.c
> @@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
> if (info.irq == NO_IRQ)
> info.irq = -1;
>
> - if (of_find_i2c_driver(node, &info) < 0) {
> - irq_dispose_mapping(info.irq);
> - continue;
> - }
> + if (of_find_i2c_driver(node, &info) < 0)
> + goto err;
>
> info.addr = *addr;
>
> @@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
> printk(KERN_ERR
> "of-i2c: Failed to load driver for %s\n",
> info.type);
> - irq_dispose_mapping(info.irq);
> - continue;
> + goto err;
> }
> + continue;
> +err:
> + if (info.irq > 0)
> + irq_dispose_mapping(info.irq);
> }
> }
> EXPORT_SYMBOL(of_register_i2c_devices);
> --
> 1.5.5.4
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: [PATCH 1/2] Convert i2c-mpc from a platform driver into a of_platform driver, V4
From: Grant Likely @ 2008-07-11 18:12 UTC (permalink / raw)
To: Timur Tabi; +Cc: Linuxppc-dev, i2c
In-Reply-To: <8EAD138A-6CE4-4AC7-BCBF-13B8E7C24CF1@freescale.com>
On Thu, Jul 10, 2008 at 12:36:58PM -0400, Timur Tabi wrote:
>
> On Jul 9, 2008, at 1:22 PM, Grant Likely wrote:
>
>> On Mon, Jun 30, 2008 at 5:01 PM, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> Convert i2c-mpc to an of_platform driver. Utilize the code in
>>> drivers/of-i2c.c to make i2c modules dynamically loadable by the
>>> device tree.
>>
>> Timur, can you please test this one on an 83xx platform? It works on
>> 5200, but I want to make sure 83xx doesn't break before I pick it up.
>
> I'm on vacation this week, so I'll have to deal with it next week, after
> I've handled higher-priority issues.
Kumar, is there anyone else who can test this out before the merge
window opens?
OTOH, it should be pretty safe. It's been tested on 5200. I could just
pick it up without 8xxx testing if you're okay with it.
g.
^ permalink raw reply
* [PATCH] of/i2c: don't pass -1 to irq_dispose_mapping, otherwise kernel will oops
From: Anton Vorontsov @ 2008-07-11 17:48 UTC (permalink / raw)
To: linuxppc-dev
Firstly kernel warns at set_irq_chip, and then dies completely:
Trying to install chip for IRQ-1
------------[ cut here ]------------
Badness at c00463b0 [verbose debug info unavailable]
NIP: c00463b0 LR: c00463b0 CTR: c0158e80
REGS: cf821cd0 TRAP: 0700 Not tainted (2.6.26-rc8-next-20080704-20216-g7bcfaff-dirty)
MSR: 00029032 <EE,ME,IR,DR> CR: 24044042 XER: 20000000
TASK = cf81f8a0[1] 'swapper' THREAD: cf820000
GPR00: c00463b0 cf821d80 cf81f8a0 00000024 000015cb ffffffff c015c1fc 00004000
GPR08: c035e960 c0350000 c035e4b8 000015cb 84044042 00000000 0fffd000 00000000
GPR16: 0fff3028 0fff6cf0 00000000 0fff8390 0ff494a0 00000004 00000000 c02ef520
GPR24: cf934210 cf821dfc c02ef4f8 c035ac08 00000000 ffffffff ffffffff 00000000
NIP [c00463b0] set_irq_chip+0x90/0x9c
LR [c00463b0] set_irq_chip+0x90/0x9c
Call Trace:
[cf821d80] [c00463b0] set_irq_chip+0x90/0x9c (unreliable)
[cf821da0] [c004641c] set_irq_chip_and_handler+0x1c/0x40
[cf821dc0] [c0005a64] irq_dispose_mapping+0x70/0x13c
[cf821df0] [c01ebf10] of_register_i2c_devices+0x124/0x504
[cf821e50] [c0276f78] 0xc0276f78
[cf821e70] [c01eba20] of_platform_device_probe+0x5c/0x84
[cf821e90] [c0160724] really_probe+0x78/0x1a8
[cf821eb0] [c016095c] __driver_attach+0x84/0x88
[cf821ed0] [c015fc14] bus_for_each_dev+0x5c/0x98
[cf821f00] [c016056c] driver_attach+0x24/0x34
[cf821f10] [c0160220] bus_add_driver+0xb4/0x1cc
[cf821f30] [c0160c4c] driver_register+0x5c/0x114
[cf821f40] [c01eb8e8] of_register_driver+0x54/0x70
[cf821f50] [c032a2e0] fsl_i2c_init+0x24/0x54
[cf821f60] [c0310244] do_one_initcall+0x34/0x198
[cf821fd0] [c03103e0] do_initcalls+0x38/0x58
[cf821fe0] [c0310464] kernel_init+0x30/0x90
[cf821ff0] [c000f944] kernel_thread+0x44/0x60
Instruction dump:
80010024 bba10014 38210020 7c0803a6 4e800020 3d20c034 3be977b8 4bffffac
3c60c02d 7fc4f378 386329e0 4bfd6465 <0fe00000> 3860ffea 4bffffc8 9421ffe0
Trying to install type control for IRQ-1
Unable to handle kernel paging request for data at address 0x3863ce7c
Faulting instruction address: 0xc0005a68
Oops: Kernel access of bad area, sig: 11 [#1]
MPC837x RDB
Modules linked in:
NIP: c0005a68 LR: c0005a64 CTR: c0158e80
REGS: cf821d10 TRAP: 0300 Not tainted (2.6.26-rc8-next-20080704-20216-g7bcfaff-dirty)
MSR: 00009032 <EE,ME,IR,DR> CR: 24044042 XER: 20000000
DAR: 3863ce7c, DSISR: 20000000
TASK = cf81f8a0[1] 'swapper' THREAD: cf820000
GPR00: c0005a64 cf821dc0 cf81f8a0 0000002c 00001d4f ffffffff c015c1fc 00004000
GPR08: c035e960 3863ce74 c035e4b8 00001d4f 24044042 00000000 0fffd000 00000000
GPR16: 0fff3028 0fff6cf0 00000000 0fff8390 0ff494a0 00000004 00000000 c02ef520
GPR24: cf934210 cf821dfc c02ef4f8 c035ac08 cf821df8 fffffff8 ffffffff c000d9f0
NIP [c0005a68] irq_dispose_mapping+0x74/0x13c
LR [c0005a64] irq_dispose_mapping+0x70/0x13c
Call Trace:
[cf821dc0] [c0005a64] irq_dispose_mapping+0x70/0x13c (unreliable)
[cf821df0] [c01ebf10] of_register_i2c_devices+0x124/0x504
[cf821e50] [c0276f78] 0xc0276f78
[cf821e70] [c01eba20] of_platform_device_probe+0x5c/0x84
[cf821e90] [c0160724] really_probe+0x78/0x1a8
[cf821eb0] [c016095c] __driver_attach+0x84/0x88
[cf821ed0] [c015fc14] bus_for_each_dev+0x5c/0x98
[cf821f00] [c016056c] driver_attach+0x24/0x34
[cf821f10] [c0160220] bus_add_driver+0xb4/0x1cc
[cf821f30] [c0160c4c] driver_register+0x5c/0x114
[cf821f40] [c01eb8e8] of_register_driver+0x54/0x70
[cf821f50] [c032a2e0] fsl_i2c_init+0x24/0x54
[cf821f60] [c0310244] do_one_initcall+0x34/0x198
[cf821fd0] [c03103e0] do_initcalls+0x38/0x58
[cf821fe0] [c0310464] kernel_init+0x30/0x90
[cf821ff0] [c000f944] kernel_thread+0x44/0x60
Instruction dump:
5400d97e 0f000000 2f9f0000 41beffc8 801f0008 2f800000 41beffbc 7fc3f378
38800000 38a00000 480409a1 813f0018 <80090008> 2f800000 419e0014 7fe3fb78
---[ end trace 1db4087de5c456f2 ]---
Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
drivers/of/of_i2c.c | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index b2ccdcb..95a24de 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -93,10 +93,8 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
if (info.irq == NO_IRQ)
info.irq = -1;
- if (of_find_i2c_driver(node, &info) < 0) {
- irq_dispose_mapping(info.irq);
- continue;
- }
+ if (of_find_i2c_driver(node, &info) < 0)
+ goto err;
info.addr = *addr;
@@ -107,9 +105,12 @@ void of_register_i2c_devices(struct i2c_adapter *adap,
printk(KERN_ERR
"of-i2c: Failed to load driver for %s\n",
info.type);
- irq_dispose_mapping(info.irq);
- continue;
+ goto err;
}
+ continue;
+err:
+ if (info.irq > 0)
+ irq_dispose_mapping(info.irq);
}
}
EXPORT_SYMBOL(of_register_i2c_devices);
--
1.5.5.4
^ permalink raw reply related
* Re: Freescale UCC_GETH Half Duplex Patch
From: Kim Phillips @ 2008-07-11 17:46 UTC (permalink / raw)
To: rmcguire; +Cc: linuxppc-embedded
In-Reply-To: <2FE8E39946EE489FBAFC327EC9154EAF@absolutdaddy>
On Thu, 10 Jul 2008 17:23:31 -0700
"Russell McGuire" <rmcguire@videopresence.com> wrote:
Hi Russel,
> Here is a fix up for the UCC_GETH driver supporting half duplex mode for
> some specific modes.
>
> I have tested this quiet extensively and the link now comes up and works,
> however not sure if there are other issues that need to be looked at, since
> 10BaseT connectivity provides VERY ERRATIC throughput, but at least it works
> now with RGMII and GMII modes.
good
> There was a lot more in my patch, but I removed a lot of the code for
> submission. Let me know if for any reason this patch file is improperly
> formatted.
It needs to be sent to the netdev mailing list, and see if you can get
rid of the MIME-encoding (see linux-2.6/Documentation/email-clients.txt).
And don't forget to add a signed-off-by line, too.
Kim
^ permalink raw reply
* insmod: unresolved symbol XIo_In32/XIo_Out32
From: Juliana Su @ 2008-07-11 14:26 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Is anybody familiar with the following error?
insmod: unresolved symbol XIo_In32
insmod: unresolved symbol XIo_Out32
I am trying to write a device driver for a Custom IP and get it to run
on a Xilinx ML310's Linux OS. I am using Xilinx EDK 10.1 and MontaVista
Linux version 2.4.20_mvl31-ml300. I ran into this error when trying to
load my module into the kernel. When I try to load the module using
insmod on the ".o" file, the module refuses to load and gives me the
unresolved symbol error message. I actually stumbled upon an older
posting from June 2006 on this mailing list that described a similar
problem, but those suggestions did not help me. Maybe two years later,
there are more ideas/suggestions/solutions to this problem?
Thanks!
-Juliana
^ permalink raw reply
* Re: [PATCH] [V2] powerpc: Xilinx: PS2: driver updates based on review
From: Grant Likely @ 2008-07-11 14:45 UTC (permalink / raw)
To: John Linn; +Cc: Sadanand, dmitry.torokhov, linuxppc-dev, linux-input
In-Reply-To: <20080710193451.ED2B51D18066@mail97-dub.bigfish.com>
On Thu, Jul 10, 2008 at 12:34:43PM -0700, John Linn wrote:
> Review comments were incorporated to improve the driver.
>
> 1. Some data was eliminated that was not needed.
> 2. Renaming of variables for clarity.
> 3. Removed unneeded type casting.
> 4. Changed to use dev_err rather than other I/O.
> 5. Merged together some functions.
> 6. Added kerneldoc format to functions.
>
> Signed-off-by: Sadanand <sadanan@xilinx.com>
> Signed-off-by: John Linn <john.linn@xilinx.com>
Acked-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> This patch is an incremental patch to be applied to
> [V3] powerpc: Xilinx: PS2: Added new XPS PS2 driver.
>
> V2
> Updated based on Peter's comments.
>
> drivers/input/serio/xilinx_ps2.c | 207 ++++++++++++++++++++------------------
> 1 files changed, 111 insertions(+), 96 deletions(-)
>
> diff --git a/drivers/input/serio/xilinx_ps2.c b/drivers/input/serio/xilinx_ps2.c
> index e86f11b..86ec91c 100644
> --- a/drivers/input/serio/xilinx_ps2.c
> +++ b/drivers/input/serio/xilinx_ps2.c
> @@ -58,23 +58,20 @@
>
> /* Mask for all the Receive Interrupts */
> #define XPS2_IPIXR_RX_ALL (XPS2_IPIXR_RX_OVF | XPS2_IPIXR_RX_ERR | \
> - XPS2_IPIXR_RX_FULL)
> + XPS2_IPIXR_RX_FULL)
>
> /* Mask for all the Interrupts */
> #define XPS2_IPIXR_ALL (XPS2_IPIXR_TX_ALL | XPS2_IPIXR_RX_ALL | \
> - XPS2_IPIXR_WDT_TOUT)
> + XPS2_IPIXR_WDT_TOUT)
>
> /* Global Interrupt Enable mask */
> #define XPS2_GIER_GIE_MASK 0x80000000
>
> struct xps2data {
> int irq;
> - u32 phys_addr;
> - u32 remap_size;
> spinlock_t lock;
> - u8 rxb; /* Rx buffer */
> void __iomem *base_address; /* virt. address of control registers */
> - unsigned int dfl;
> + unsigned int flags;
> struct serio serio; /* serio */
> };
>
> @@ -82,8 +79,13 @@ struct xps2data {
> /* XPS PS/2 data transmission calls */
> /************************************/
>
> -/*
> - * xps2_recv() will attempt to receive a byte of data from the PS/2 port.
> +/**
> + * xps2_recv() - attempts to receive a byte from the PS/2 port.
> + * @drvdata: pointer to ps2 device private data structure
> + * @byte: address where the read data will be copied
> + *
> + * If there is any data available in the PS/2 receiver, this functions reads
> + * the data, otherwise it returns error.
> */
> static int xps2_recv(struct xps2data *drvdata, u8 *byte)
> {
> @@ -105,7 +107,7 @@ static int xps2_recv(struct xps2data *drvdata, u8 *byte)
> /*********************/
> static irqreturn_t xps2_interrupt(int irq, void *dev_id)
> {
> - struct xps2data *drvdata = (struct xps2data *)dev_id;
> + struct xps2data *drvdata = dev_id;
> u32 intr_sr;
> u8 c;
> int status;
> @@ -115,35 +117,28 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
> out_be32(drvdata->base_address + XPS2_IPISR_OFFSET, intr_sr);
>
> /* Check which interrupt is active */
> - if (intr_sr & XPS2_IPIXR_RX_OVF) {
> - printk(KERN_ERR "%s: receive overrun error\n",
> - drvdata->serio.name);
> - }
> + if (intr_sr & XPS2_IPIXR_RX_OVF)
> + dev_err(drvdata->serio.dev.parent, "receive overrun error\n");
>
> if (intr_sr & XPS2_IPIXR_RX_ERR)
> - drvdata->dfl |= SERIO_PARITY;
> + drvdata->flags |= SERIO_PARITY;
>
> if (intr_sr & (XPS2_IPIXR_TX_NOACK | XPS2_IPIXR_WDT_TOUT))
> - drvdata->dfl |= SERIO_TIMEOUT;
> + drvdata->flags |= SERIO_TIMEOUT;
>
> if (intr_sr & XPS2_IPIXR_RX_FULL) {
> - status = xps2_recv(drvdata, &drvdata->rxb);
> + status = xps2_recv(drvdata, &c);
>
> /* Error, if a byte is not received */
> if (status) {
> - printk(KERN_ERR
> - "%s: wrong rcvd byte count (%d)\n",
> - drvdata->serio.name, status);
> + dev_err(drvdata->serio.dev.parent,
> + "wrong rcvd byte count (%d)\n", status);
> } else {
> - c = drvdata->rxb;
> - serio_interrupt(&drvdata->serio, c, drvdata->dfl);
> - drvdata->dfl = 0;
> + serio_interrupt(&drvdata->serio, c, drvdata->flags);
> + drvdata->flags = 0;
> }
> }
>
> - if (intr_sr & XPS2_IPIXR_TX_ACK)
> - drvdata->dfl = 0;
> -
> return IRQ_HANDLED;
> }
>
> @@ -151,8 +146,15 @@ static irqreturn_t xps2_interrupt(int irq, void *dev_id)
> /* serio callbacks */
> /*******************/
>
> -/*
> - * sxps2_write() sends a byte out through the PS/2 interface.
> +/**
> + * sxps2_write() - sends a byte out through the PS/2 port.
> + * @pserio: pointer to the serio structure of the PS/2 port
> + * @c: data that needs to be written to the PS/2 port
> + *
> + * This function checks if the PS/2 transmitter is empty and sends a byte.
> + * Otherwise it returns error. Transmission fails only when nothing is connected
> + * to the PS/2 port. Thats why, we do not try to resend the data in case of a
> + * failure.
> */
> static int sxps2_write(struct serio *pserio, unsigned char c)
> {
> @@ -173,33 +175,39 @@ static int sxps2_write(struct serio *pserio, unsigned char c)
> return status;
> }
>
> -/*
> - * sxps2_open() is called when a port is open by the higher layer.
> +/**
> + * sxps2_open() - called when a port is opened by the higher layer.
> + * @pserio: pointer to the serio structure of the PS/2 device
> + *
> + * This function requests irq and enables interrupts for the PS/2 device.
> */
> static int sxps2_open(struct serio *pserio)
> {
> struct xps2data *drvdata = pserio->port_data;
> int retval;
> + u8 c;
>
> retval = request_irq(drvdata->irq, &xps2_interrupt, 0,
> DRIVER_NAME, drvdata);
> if (retval) {
> - printk(KERN_ERR
> - "%s: Couldn't allocate interrupt %d\n",
> - drvdata->serio.name, drvdata->irq);
> + dev_err(drvdata->serio.dev.parent,
> + "Couldn't allocate interrupt %d\n", drvdata->irq);
> return retval;
> }
>
> /* start reception by enabling the interrupts */
> out_be32(drvdata->base_address + XPS2_GIER_OFFSET, XPS2_GIER_GIE_MASK);
> out_be32(drvdata->base_address + XPS2_IPIER_OFFSET, XPS2_IPIXR_RX_ALL);
> - (void)xps2_recv(drvdata, &drvdata->rxb);
> + (void)xps2_recv(drvdata, &c);
>
> return 0; /* success */
> }
>
> -/*
> - * sxps2_close() frees the interrupt.
> +/**
> + * sxps2_close() - frees the interrupt.
> + * @pserio: pointer to the serio structure of the PS/2 device
> + *
> + * This function frees the irq and disables interrupts for the PS/2 device.
> */
> static void sxps2_close(struct serio *pserio)
> {
> @@ -211,21 +219,48 @@ static void sxps2_close(struct serio *pserio)
> free_irq(drvdata->irq, drvdata);
> }
>
> -/*********************/
> -/* Device setup code */
> -/*********************/
> -
> -static int xps2_setup(struct device *dev, struct resource *regs_res,
> - struct resource *irq_res)
> +/**
> + * xps2_of_probe - probe method for the PS/2 device.
> + * @of_dev: pointer to OF device structure
> + * @match: pointer to the stucture used for matching a device
> + *
> + * This function probes the PS/2 device in the device tree.
> + * It initializes the driver data structure and the hardware.
> + * It returns 0, if the driver is bound to the PS/2 device, or a negative
> + * value if there is an error.
> + */
> +static int __devinit xps2_of_probe(struct of_device *ofdev, const struct
> + of_device_id * match)
> {
> + struct resource r_irq; /* Interrupt resources */
> + struct resource r_mem; /* IO mem resources */
> struct xps2data *drvdata;
> struct serio *serio;
> - unsigned long remap_size;
> - int retval;
> + struct device *dev;
> + resource_size_t remap_size, phys_addr;
> + int rc = 0;
>
> + dev = &ofdev->dev;
> if (!dev)
> return -EINVAL;
>
> + dev_info(dev, "Device Tree Probing \'%s\'\n",
> + ofdev->node->name);
> +
> + /* Get iospace for the device */
> + rc = of_address_to_resource(ofdev->node, 0, &r_mem);
> + if (rc) {
> + dev_err(dev, "invalid address\n");
> + return rc;
> + }
> +
> + /* Get IRQ for the device */
> + rc = of_irq_to_resource(ofdev->node, 0, &r_irq);
> + if (rc == NO_IRQ) {
> + dev_err(dev, "no IRQ found\n");
> + return rc;
> + }
> +
> drvdata = kzalloc(sizeof(struct xps2data), GFP_KERNEL);
> if (!drvdata) {
> dev_err(dev, "Couldn't allocate device private record\n");
> @@ -234,31 +269,24 @@ static int xps2_setup(struct device *dev, struct resource *regs_res,
> spin_lock_init(&drvdata->lock);
> dev_set_drvdata(dev, drvdata);
>
> - if (!regs_res || !irq_res) {
> - dev_err(dev, "IO resource(s) not found\n");
> - retval = -EFAULT;
> - goto failed1;
> - }
> -
> - drvdata->irq = irq_res->start;
> - remap_size = regs_res->end - regs_res->start + 1;
> - if (!request_mem_region(regs_res->start, remap_size, DRIVER_NAME)) {
> + drvdata->irq = r_irq.start;
> + phys_addr = r_mem.start;
> + remap_size = r_mem.end - r_mem.start + 1;
> + if (!request_mem_region(phys_addr, remap_size, DRIVER_NAME)) {
>
> dev_err(dev, "Couldn't lock memory region at 0x%08X\n",
> - (unsigned int)regs_res->start);
> - retval = -EBUSY;
> + (unsigned int)phys_addr);
> + rc = -EBUSY;
> goto failed1;
> }
>
> /* Fill in configuration data and add them to the list */
> - drvdata->phys_addr = regs_res->start;
> - drvdata->remap_size = remap_size;
> - drvdata->base_address = ioremap(regs_res->start, remap_size);
> + drvdata->base_address = ioremap(phys_addr, remap_size);
> if (drvdata->base_address == NULL) {
>
> dev_err(dev, "Couldn't ioremap memory at 0x%08X\n",
> - (unsigned int)regs_res->start);
> - retval = -EFAULT;
> + (unsigned int)phys_addr);
> + rc = -EFAULT;
> goto failed2;
> }
>
> @@ -270,7 +298,8 @@ static int xps2_setup(struct device *dev, struct resource *regs_res,
> out_be32(drvdata->base_address + XPS2_SRST_OFFSET, XPS2_SRST_RESET);
>
> dev_info(dev, "Xilinx PS2 at 0x%08X mapped to 0x%08X, irq=%d\n",
> - drvdata->phys_addr, (u32)drvdata->base_address, drvdata->irq);
> + (unsigned int)phys_addr, (u32)drvdata->base_address,
> + drvdata->irq);
>
> serio = &drvdata->serio;
> serio->id.type = SERIO_8042;
> @@ -280,58 +309,37 @@ static int xps2_setup(struct device *dev, struct resource *regs_res,
> serio->port_data = drvdata;
> serio->dev.parent = dev;
> snprintf(drvdata->serio.name, sizeof(serio->name),
> - "Xilinx XPS PS/2 at %08X", drvdata->phys_addr);
> + "Xilinx XPS PS/2 at %08X", (unsigned int)phys_addr);
> snprintf(drvdata->serio.phys, sizeof(serio->phys),
> - "xilinxps2/serio at %08X", drvdata->phys_addr);
> + "xilinxps2/serio at %08X", (unsigned int)phys_addr);
> serio_register_port(serio);
>
> return 0; /* success */
>
> failed2:
> - release_mem_region(regs_res->start, remap_size);
> + release_mem_region(phys_addr, remap_size);
>
> failed1:
> kfree(drvdata);
> dev_set_drvdata(dev, NULL);
>
> - return retval;
> -}
> -
> -/***************************/
> -/* OF Platform Bus Support */
> -/***************************/
> -
> -static int __devinit xps2_of_probe(struct of_device *ofdev, const struct
> - of_device_id * match)
> -{
> - struct resource r_irq; /* Interrupt resources */
> - struct resource r_mem; /* IO mem resources */
> - int rc = 0;
> -
> - printk(KERN_INFO "Device Tree Probing \'%s\'\n",
> - ofdev->node->name);
> -
> - /* Get iospace for the device */
> - rc = of_address_to_resource(ofdev->node, 0, &r_mem);
> - if (rc) {
> - dev_err(&ofdev->dev, "invalid address\n");
> - return rc;
> - }
> -
> - /* Get IRQ for the device */
> - rc = of_irq_to_resource(ofdev->node, 0, &r_irq);
> - if (rc == NO_IRQ) {
> - dev_err(&ofdev->dev, "no IRQ found\n");
> - return rc;
> - }
> -
> - return xps2_setup(&ofdev->dev, &r_mem, &r_irq);
> + return rc;
> }
>
> +/**
> + * xps2_of_remove - unbinds the driver from the PS/2 device.
> + * @of_dev: pointer to OF device structure
> + *
> + * This function is called if a device is physically removed from the system or
> + * if the driver module is being unloaded. It frees any resources allocated to
> + * the device.
> + */
> static int __devexit xps2_of_remove(struct of_device *of_dev)
> {
> struct xps2data *drvdata;
> struct device *dev;
> + struct resource r_mem; /* IO mem resources */
> + int rc;
>
> dev = &of_dev->dev;
> if (!dev)
> @@ -343,7 +351,14 @@ static int __devexit xps2_of_remove(struct of_device *of_dev)
>
> iounmap(drvdata->base_address);
>
> - release_mem_region(drvdata->phys_addr, drvdata->remap_size);
> + /* Get iospace of the device */
> + rc = of_address_to_resource(of_dev->node, 0, &r_mem);
> + if (rc) {
> + dev_err(dev, "invalid address\n");
> + return rc;
> + }
> +
> + release_mem_region(r_mem.start, r_mem.end - r_mem.start + 1);
>
> kfree(drvdata);
> dev_set_drvdata(dev, NULL);
> --
> 1.5.2.1
>
>
>
> This email and any attachments are intended for the sole use of the named recipient(s) and contain(s) confidential information that may be proprietary, privileged or copyrighted under applicable law. If you are not the intended recipient, do not read, copy, or forward this email message or any attachments. Delete this email message and any attachments immediately.
>
>
^ permalink raw reply
* OF next: microblaze movement
From: Michal Simek @ 2008-07-11 14:14 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev
Hi All,
Can you review OF files which I have in microblaze pack for linux-next?
Patch is available at
http://kerneltrap.org/mailarchive/linux-kernel/2008/7/8/2387284
Thanks,
Michal Simek
^ permalink raw reply
* [PATCH 1/4][V2] powerpc : add support for linux, usable-memory properties for drconf memory
From: Chandru @ 2008-07-11 13:49 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, Michael Neuling, kexec
In-Reply-To: <200807111639.22032.chandru@in.ibm.com>
Scan for linux,usable-memory properties in case of dynamic reconfiguration
memory. Support for kexec/kdump.
Signed-off-by: Chandru Siddalingappa <chandru@in.ibm.com>
---
Patch applies on linux-next tree (patch-v2.6.26-rc9-next-20080711.gz)
arch/powerpc/kernel/prom.c | 40 +++++++++++++++++++++++------
arch/powerpc/mm/numa.c | 48 ++++++++++++++++++++++++-----------
2 files changed, 65 insertions(+), 23 deletions(-)
diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c
linux-2.6.26-rc9/arch/powerpc/kernel/prom.c
--- linux-2.6.26-rc9-orig/arch/powerpc/kernel/prom.c 2008-07-11
14:44:55.000000000 +0530
+++ linux-2.6.26-rc9/arch/powerpc/kernel/prom.c 2008-07-11 14:58:26.000000000
+0530
@@ -888,9 +888,10 @@ static u64 __init dt_mem_next_cell(int s
*/
static int __init early_init_dt_scan_drconf_memory(unsigned long node)
{
- cell_t *dm, *ls;
- unsigned long l, n, flags;
+ cell_t *dm, *ls, *usm;
+ unsigned long l, n, flags, ranges;
u64 base, size, lmb_size;
+ char buf[32];
ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
@@ -914,14 +915,37 @@ static int __init early_init_dt_scan_drc
or if the block is not assigned to this partition (0x8) */
if ((flags & 0x80) || !(flags & 0x8))
continue;
- size = lmb_size;
- if (iommu_is_off) {
+ if (iommu_is_off)
if (base >= 0x80000000ul)
continue;
- if ((base + size) > 0x80000000ul)
- size = 0x80000000ul - base;
- }
- lmb_add(base, size);
+ size = lmb_size;
+
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+ sprintf(buf, "linux,usable-memory%d", (int)n);
+ usm = of_get_flat_dt_prop(node, buf, &l);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (l >> 2)/(dt_root_addr_cells
+ + dt_root_size_cells);
+ do {
+ if (usm != NULL) {
+ base = dt_mem_next_cell(dt_root_addr_cells,
+ &usm);
+ size = dt_mem_next_cell(dt_root_size_cells,
+ &usm);
+ if (size == 0)
+ break;
+ }
+ if (iommu_is_off)
+ if ((base + size) > 0x80000000ul)
+ size = 0x80000000ul - base;
+
+ lmb_add(base, size);
+ } while (--ranges);
}
lmb_dump_all();
return 0;
diff -Naurp linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c
linux-2.6.26-rc9/arch/powerpc/mm/numa.c
--- linux-2.6.26-rc9-orig/arch/powerpc/mm/numa.c 2008-07-11 14:44:55.000000000
+0530
+++ linux-2.6.26-rc9/arch/powerpc/mm/numa.c 2008-07-11 15:01:56.000000000
+0530
@@ -493,11 +493,13 @@ static unsigned long __init numa_enforce
*/
static void __init parse_drconf_memory(struct device_node *memory)
{
- const u32 *dm;
- unsigned int n, rc;
- unsigned long lmb_size, size;
+ const u32 *dm, *usm;
+ unsigned int n, rc, len, ranges;
+ unsigned long lmb_size, size, sz;
int nid;
struct assoc_arrays aa;
+ char buf[32];
+ u64 base;
n = of_get_drconf_memory(memory, &dm);
if (!n)
@@ -524,19 +526,35 @@ static void __init parse_drconf_memory(s
nid = of_drconf_to_nid_single(&drmem, &aa);
- fake_numa_create_new_node(
- ((drmem.base_addr + lmb_size) >> PAGE_SHIFT),
- &nid);
-
- node_set_online(nid);
-
- size = numa_enforce_memory_limit(drmem.base_addr, lmb_size);
- if (!size)
- continue;
+ /*
+ * Append 'n' to 'linux,usable-memory' to get special
+ * properties passed in by tools like kexec-tools. Relevant
+ * only if this is a kexec/kdump kernel.
+ */
+ sprintf(buf, "linux,usable-memory%d", (int)n);
+ usm = of_get_property(memory, buf, &len);
+ ranges = 1;
+ if (usm != NULL)
+ ranges = (len >> 2) /
+ (n_mem_addr_cells + n_mem_size_cells);
+
+ base = drmem.base_addr;
+ size = lmb_size;
+ do {
+ if (usm != NULL) {
+ base = read_n_cells(n_mem_addr_cells, &usm);
+ size = read_n_cells(n_mem_size_cells, &usm);
+ }
- add_active_range(nid, drmem.base_addr >> PAGE_SHIFT,
- (drmem.base_addr >> PAGE_SHIFT)
- + (size >> PAGE_SHIFT));
+ fake_numa_create_new_node(((base + size) >> PAGE_SHIFT),
+ &nid);
+ node_set_online(nid);
+ sz = numa_enforce_memory_limit(base, size);
+ if (sz)
+ add_active_range(nid, base >> PAGE_SHIFT,
+ (base >> PAGE_SHIFT)
+ + (sz >> PAGE_SHIFT));
+ } while (--ranges);
}
}
^ permalink raw reply
* Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Rusty Russell @ 2008-07-11 12:34 UTC (permalink / raw)
To: Ingo Molnar
Cc: Stephen Rothwell, linux-kernel, Milton Miller, linuxppc-dev,
linux-next, Andrew Morton, Ingo Molnar
In-Reply-To: <20080711074602.GB27849@elte.hu>
On Friday 11 July 2008 17:46:03 Ingo Molnar wrote:
> * Milton Miller <miltonm@bga.com> wrote:
> > Hi Rusty, Ingo.
> >
> > Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic
> > numbers didn't find kernel/trace/ftrace.c in -next, causing an
> > immediate almost NULL pointer dereference in ftrace_dynamic_init.
>
> Rusty - what's going on here? Please do not change APIs like that, which
> cause code to crash. Either do a compatible API change, or change it
> over in a way that causes clear build failures, not crashes.
To be fair, I did. Unfortunately GCC only warns about passing an int to a
pointer arg, and boom.
But compatible is even better. Given the number of stop_machine_run users I
thought it unlikely that a new one would be introduced during the change. I
was wrong, so I'll do it the Right Way.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCH 1/4] kdump : add support for ibm, dynamic-reconfiguration-memory for kexec/kdump
From: Chandru @ 2008-07-11 11:09 UTC (permalink / raw)
To: Nathan Fontenot; +Cc: linuxppc-dev, kexec
In-Reply-To: <48768CE9.2080802@austin.ibm.com>
On Friday 11 July 2008 03:57:53 Nathan Fontenot wrote:
> Hello Chandru,
>
> > static int __init early_init_dt_scan_drconf_memory(unsigned long node)
> > {
> > - cell_t *dm, *ls;
> > + cell_t *dm, *ls, *endp, *usm;
> > unsigned long l, n, flags;
> > u64 base, size, lmb_size;
> > + char buf[32], t[8];
> >
> > ls = (cell_t *)of_get_flat_dt_prop(node, "ibm,lmb-size", &l);
> > if (ls == NULL || l < dt_root_size_cells * sizeof(cell_t))
> > @@ -917,7 +918,33 @@ static int __init early_init_dt_scan_drc
> > if ((base + size) > 0x80000000ul)
> > size = 0x80000000ul - base;
> > }
> > - lmb_add(base, size);
> > + strcpy(buf, "linux,usable-memory");
> > + sprintf(t, "%d", (int)n);
> > + strcat(buf, t);
> > + usm = (cell_t *)of_get_flat_dt_prop(node,
> > + (const char *)buf, &l);
> > + if (usm != NULL) {
> > + endp = usm + (l / sizeof(cell_t));
> > + while ((endp - usm) >= (dt_root_addr_cells +
> > + dt_root_size_cells)) {
> > + base = dt_mem_next_cell(dt_root_addr_cells,
> > + &usm);
> > + size = dt_mem_next_cell(dt_root_size_cells,
> > + &usm);
> > + if (size == 0)
> > + continue;
> > + if (iommu_is_off) {
> > + if ((base + size) > 0x80000000ul)
> > + size = 0x80000000ul - base;
> > + }
> > + lmb_add(base, size);
> > + }
> > +
> > + /* Continue with next lmb entry */
> > + continue;
> > + } else {
> > + lmb_add(base, size);
> > + }
> > }
>
> I am still digging through the kexec tools but I don't think you want
> the processing of the linux,usable-memory property inside of the
> for (; n!= 0; --n) loop. This should be moved up so that it looks for
> the linux,usable-memory property and parses it, then if it is not found
> look for the ibm,dynamic-reconfiguration-memory property and parse it.
>
> There is no need to look for the linux-usable-memory property every time
> a piece of the ibm,dynamic-reconfiguration-memory property is parsed.
>
> -Nathan
Hello Nathan,
Thanks for the review. kexec-tools adds a 'linux,usable-memory' property for
each memory range listed in the device tree. If the regions are not
crashkernel or rtas or tce regions, then it sets base and size to zero but
still adds them as linux,usable-memory property. If we look at the code
above, in a kdump kernel we don't add an lmb through lmb_add() if the regions
are not one of the mentioned above. We check for (size == 0) and continue
with next lmb if it is so. We still have the complete device tree which
kexec-tools passes in as the buffer that we are scanning here and
linux,usable-memory properties aid in making kdump kernel to see only those
memory regions that it is suppose to use. I just worked on another version
of this patch based on comments from Michael Neuling and Stephen Rothwell. I
will post it shortly.
Thanks,
Chandru
^ permalink raw reply
* RE: mpc744x, Marvell mv6446x kernel guidance please
From: Welch, Martyn (GE EntSol, Intelligent Platforms) @ 2008-07-11 8:37 UTC (permalink / raw)
To: Stephen Horton, linuxppc-embedded
In-Reply-To: <295C5089A56CE143B316E5F67CA99CB001C9E4BD@cowboy.inovate.inovate.com>
On Thu, 10 Jul 2008 22:46:49 -0500
"Stephen Horton" <SHorton@kodiaknetworks.com> wrote:
> Hello folks,
>=20
> In a current work project, I have inherited a compactPCI board that
has
> an mpc7447/7448 powerpc processor as well as a Marvell system
> controller, model mv64462 (stripped down mv64460). The board has a
> somewhat working Gentoo Linux port running on it from long ago and a
> company far far away (kernel version 2.6.9 built using arch/ppc). To
> prepare for an upcoming deployment, I would like to bring the OS
> up-to-date on this board with a newer kernel (targeting Gentoo 2008),
> but I am unsure of the approach to take. I am a software developer,
but
> normally do not work on kernel porting / board integration. I have
> researched the arch/ppc to arch/powerpc migration, but I'm a bit
> intimidated by the 'new' device tree symantics and other changes to
the
> stream. Here are some questions:
>=20
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
I've had problems getting newer versions of the kernel compiling (using
the ppc arch) for some of our boards. It's going completely in the next
release cycle I believe, infact the powerpc git tree[1] no longer has a
"ppc" arch. Hence we are moving to powerpc.
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
These patches may provide a reasonable starting point:
http://www.mail-archive.com/linuxppc-dev@ozlabs.org/msg18084.html
> 3. Any advice of any kind?
Stick at it? - I've not long started kernel development and only had ppc
examples (for our boards), like you on an old kernel version (2.6.9 and
2.6.12) and what was in the kernel source. It's taken a while getting
familiar with the powerpc arch, but I'm beginning to see the benefits.
I'd suggest looking at the powerpc specific git tree. I use "stacked
git"[2] on top of this git tree and have found this a reasonably
productive way to work. Whilst learning and porting I can keep the base
up to date with "stg pull" (which peels off my changes, updates the git
tree and re-applies my changes). It also helps with creating well
formatted emails for submitting patches.
Hope this helps,
Martyn
[1] git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
[2] http://procode.org/stgit/
----
Martyn Welch MEng MPhil MIET
Principal Software Engineer
GE Fanuc Intelligent Platforms
Tove Valley Business Park, Towcester,
Northants, NN12 6PF, United Kingdom
Telephone: +44 (0) 1327 359444
Direct Dial: +44 (0) 1327 322748
Fax: +44 (0) 1327 322800
email: martyn.welch@gefanuc.com
web: www.gefanuc.com
GE Fanuc Intelligent Platforms Ltd, registered in England and Wales
(3828642) at 100 Barbirolli Square, Manchester, M2 3AB, VAT GB 729 849
476=20
GE Fanuc Intelligent Platforms Confidential and Proprietary. If you have
received this message in error please notify us immediately and
permanently remove it from your system and destroy any printed
hardcopies. =20
^ permalink raw reply
* Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Ingo Molnar @ 2008-07-11 8:55 UTC (permalink / raw)
To: Milton Miller
Cc: Stephen Rothwell, Rusty Russell, linux-kernel, linuxppc-dev,
Ingo Molnar, linux-next, Andrew Morton
In-Reply-To: <20080711074602.GB27849@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * Milton Miller <miltonm@bga.com> wrote:
>
> > Hi Rusty, Ingo.
> >
> > Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic
> > numbers didn't find kernel/trace/ftrace.c in -next, causing an
> > immediate almost NULL pointer dereference in ftrace_dynamic_init.
>
> Rusty - what's going on here? Please do not change APIs like that,
> which cause code to crash. Either do a compatible API change, or
> change it over in a way that causes clear build failures, not crashes.
ah, i see it from Rusty's other reply that there's going to be another
version of this. Good :-)
Ingo
^ permalink raw reply
* Re: [PATCH][RT][PPC64] Fix preempt unsafe paths accessing per_cpu variables
From: Sebastien Dugue @ 2008-07-11 8:19 UTC (permalink / raw)
To: Chirag Jog
Cc: linux-rt-users, Josh Triplett, Steven Rostedt, linuxppc-dev,
Nivedita Singhvi, Timothy R. Chavez, paulmck, linux.kernel
In-Reply-To: <20080709160543.GG7101@linux.vnet.ibm.com>
Hi Chirag,
On Wed, 9 Jul 2008 21:35:43 +0530 Chirag Jog <chirag@linux.vnet.ibm.com> wrote:
>
> Hi,
> This patch fixes various paths in the -rt kernel on powerpc64 where per_cpu
> variables are accessed in a preempt unsafe way.
> When a power box with -rt kernel is booted, multiple BUG messages are
> generated "BUG: init:1 task might have lost a preemption check!".
> After booting a kernel with these patches applied, these messages
> don't appear.
That does indeed greatly reduce BUGs display. Good. Thanks.
Tested-by: Sebastien Dugue <sebastien.dugue@bull.net>
Sebastien.
>
> Also I ran the realtime tests from ltp to ensure the stability.
>
>
> Signed-Off-By: Chirag <chirag@linux.vnet.ibm.com>
> arch/powerpc/mm/tlb_64.c | 31 ++++++++++++++++---------------
> arch/powerpc/platforms/pseries/iommu.c | 14 ++++++++++----
> include/asm-powerpc/tlb.h | 5 ++---
> 3 files changed, 28 insertions(+), 22 deletions(-)
>
>
> Index: linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c
> ===================================================================
> --- linux-2.6.25.8-rt7.orig/arch/powerpc/mm/tlb_64.c 2008-07-09 21:29:21.000000000 +0530
> +++ linux-2.6.25.8-rt7/arch/powerpc/mm/tlb_64.c 2008-07-09 21:30:37.000000000 +0530
> @@ -38,7 +38,6 @@
> * include/asm-powerpc/tlb.h file -- tgall
> */
> DEFINE_PER_CPU_LOCKED(struct mmu_gather, mmu_gathers);
> -DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
> unsigned long pte_freelist_forced_free;
>
> struct pte_freelist_batch
> @@ -48,7 +47,7 @@
> pgtable_free_t tables[0];
> };
>
> -DEFINE_PER_CPU(struct pte_freelist_batch *, pte_freelist_cur);
> +DEFINE_PER_CPU_LOCKED(struct pte_freelist_batch *, pte_freelist_cur);
> unsigned long pte_freelist_forced_free;
>
> #define PTE_FREELIST_SIZE \
> @@ -92,24 +91,21 @@
>
> void pgtable_free_tlb(struct mmu_gather *tlb, pgtable_free_t pgf)
> {
> - /*
> - * This is safe since tlb_gather_mmu has disabled preemption.
> - * tlb->cpu is set by tlb_gather_mmu as well.
> - */
> + int cpu;
> cpumask_t local_cpumask = cpumask_of_cpu(tlb->cpu);
> - struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
> + struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
>
> if (atomic_read(&tlb->mm->mm_users) < 2 ||
> cpus_equal(tlb->mm->cpu_vm_mask, local_cpumask)) {
> pgtable_free(pgf);
> - return;
> + goto cleanup;
> }
>
> if (*batchp == NULL) {
> *batchp = (struct pte_freelist_batch *)__get_free_page(GFP_ATOMIC);
> if (*batchp == NULL) {
> pgtable_free_now(pgf);
> - return;
> + goto cleanup;
> }
> (*batchp)->index = 0;
> }
> @@ -118,6 +114,9 @@
> pte_free_submit(*batchp);
> *batchp = NULL;
> }
> +
> + cleanup:
> + put_cpu_var_locked(pte_freelist_cur, cpu);
> }
>
> /*
> @@ -253,13 +252,15 @@
>
> void pte_free_finish(void)
> {
> - /* This is safe since tlb_gather_mmu has disabled preemption */
> - struct pte_freelist_batch **batchp = &__get_cpu_var(pte_freelist_cur);
> + int cpu;
> + struct pte_freelist_batch **batchp = &get_cpu_var_locked(pte_freelist_cur, &cpu);
>
> - if (*batchp == NULL)
> - return;
> - pte_free_submit(*batchp);
> - *batchp = NULL;
> + if (*batchp) {
> + pte_free_submit(*batchp);
> + *batchp = NULL;
> + }
> +
> + put_cpu_var_locked(pte_freelist_cur, cpu);
> }
>
> /**
> Index: linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h
> ===================================================================
> --- linux-2.6.25.8-rt7.orig/include/asm-powerpc/tlb.h 2008-07-09 21:29:21.000000000 +0530
> +++ linux-2.6.25.8-rt7/include/asm-powerpc/tlb.h 2008-07-09 21:29:41.000000000 +0530
> @@ -40,18 +40,17 @@
>
> static inline void tlb_flush(struct mmu_gather *tlb)
> {
> - struct ppc64_tlb_batch *tlbbatch = &__get_cpu_var(ppc64_tlb_batch);
> + struct ppc64_tlb_batch *tlbbatch = &get_cpu_var(ppc64_tlb_batch);
>
> /* If there's a TLB batch pending, then we must flush it because the
> * pages are going to be freed and we really don't want to have a CPU
> * access a freed page because it has a stale TLB
> */
> if (tlbbatch->index) {
> - preempt_disable();
> __flush_tlb_pending(tlbbatch);
> - preempt_enable();
> }
>
> + put_cpu_var(ppc64_tlb_batch);
> pte_free_finish();
> }
>
> Index: linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c
> ===================================================================
> --- linux-2.6.25.8-rt7.orig/arch/powerpc/platforms/pseries/iommu.c 2008-07-09 21:29:21.000000000 +0530
> +++ linux-2.6.25.8-rt7/arch/powerpc/platforms/pseries/iommu.c 2008-07-09 21:29:41.000000000 +0530
> @@ -124,7 +124,7 @@
> }
> }
>
> -static DEFINE_PER_CPU(u64 *, tce_page) = NULL;
> +static DEFINE_PER_CPU_LOCKED(u64 *, tce_page) = NULL;
>
> static void tce_buildmulti_pSeriesLP(struct iommu_table *tbl, long tcenum,
> long npages, unsigned long uaddr,
> @@ -135,12 +135,13 @@
> u64 *tcep;
> u64 rpn;
> long l, limit;
> + int cpu;
>
> if (npages == 1)
> return tce_build_pSeriesLP(tbl, tcenum, npages, uaddr,
> direction);
>
> - tcep = __get_cpu_var(tce_page);
> + tcep = get_cpu_var_locked(tce_page, &cpu);
>
> /* This is safe to do since interrupts are off when we're called
> * from iommu_alloc{,_sg}()
> @@ -148,10 +149,13 @@
> if (!tcep) {
> tcep = (u64 *)__get_free_page(GFP_ATOMIC);
> /* If allocation fails, fall back to the loop implementation */
> - if (!tcep)
> + if (!tcep) {
> + put_cpu_var_locked(tce_page, cpu);
> return tce_build_pSeriesLP(tbl, tcenum, npages,
> uaddr, direction);
> - __get_cpu_var(tce_page) = tcep;
> + }
> +
> + per_cpu_var_locked(tce_page, cpu) = tcep;
> }
>
> rpn = (virt_to_abs(uaddr)) >> TCE_SHIFT;
> @@ -188,6 +192,8 @@
> printk("\ttce[0] val = 0x%lx\n", tcep[0]);
> show_stack(current, (unsigned long *)__get_SP());
> }
> +
> + put_cpu_var_locked(tce_page, cpu);
> }
>
> static void tce_free_pSeriesLP(struct iommu_table *tbl, long tcenum, long npages)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Ingo Molnar @ 2008-07-11 7:46 UTC (permalink / raw)
To: Milton Miller
Cc: Stephen Rothwell, Rusty Russell, linux-kernel, linuxppc-dev,
Ingo Molnar, linux-next, Andrew Morton
In-Reply-To: <for-27-patch0-1@bga.com>
* Milton Miller <miltonm@bga.com> wrote:
> Hi Rusty, Ingo.
>
> Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic
> numbers didn't find kernel/trace/ftrace.c in -next, causing an
> immediate almost NULL pointer dereference in ftrace_dynamic_init.
Rusty - what's going on here? Please do not change APIs like that, which
cause code to crash. Either do a compatible API change, or change it
over in a way that causes clear build failures, not crashes.
Ingo
^ permalink raw reply
* gigantci pages patches
From: Stephen Rothwell @ 2008-07-11 7:45 UTC (permalink / raw)
To: benh, paulus, npiggin, Jon Tollefson; +Cc: ppc-dev, Andrew Morton
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
Hi all,
Could people take one last look at these patches and if there are no
issues, please send Ack-bys to Andrew who will push them to Linus for
2.6.27.
[PATCH 1/6 v2] allow arch specific function for allocating gigantic pages
http://patchwork.ozlabs.org/linuxppc/patch?&id=18437
Patch: [PATCH 2/6 v2] powerpc: function for allocating gigantic pages
http://patchwork.ozlabs.org/linuxppc/patch?&id=18438
Patch: [PATCH 3/6 v2] powerpc: scan device tree and save gigantic page locations
http://patchwork.ozlabs.org/linuxppc/patch?&id=18439
Patch: [PATCH 4/6 v2] powerpc: define page support for 16G pages
http://patchwork.ozlabs.org/linuxppc/patch?&id=18440
Patch: [PATCH 5/6 v2] check for overflow
http://patchwork.ozlabs.org/linuxppc/patch?&id=18441
Patch: [PATCH 6/6] powerpc: support multiple huge page sizes
http://patchwork.ozlabs.org/linuxppc/patch?&id=18442
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-11 7:36 UTC (permalink / raw)
To: Hans de Goede
Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, Milton Miller,
lm-sensors
In-Reply-To: <48770B5E.7000308@hhs.nl>
On Fri, 11 Jul 2008 09:27:26 +0200, Hans de Goede wrote:
> Jean Delvare wrote:
> > Hi Hans, hi Milton,
> >
>
> <snip>
>
> >> One could make a superio driver, and create sub-devices for the IR,
> >> I2C, floppy, parallel, etc
> >> nodes.
> >
> > There have been proposals to do this, and this would indeed be a very
> > good idea, but unfortunately nobody took the time to implement this
> > properly, push it upstream and volunteer to maintain it. The problem is
> > that you don't need just a "driver", but a new subsystem, that needs to
> > be designed and maintained.
>
> Well, I believe there have been some lightweight superio locking coordinator
> patches been floating around on the lm_sensors list, and I have reviewed them
> and then a new version was done with my issues fixed.
>
> I kinda liked the proposed solution there, it was quite simple, moved all the
> generic superio stuff into generic superio code, and added locking for super io
> access from multiple drivers, what ever happened to those patches?
As far as I know, nothing, and this is the problem. Somebody needs to
step up and call him/herself the maintainer of the new code, and push
it upstream and convert all the drivers (hwmon, watchdog, parallel
port...) to make use of it. And I am not the one to do this, I am busy
enough as is with i2c and hwmon.
> If were to start using those, we could actually do a request region and then
> never release it, as things should be.
Yes, if we have a superio access coordinator, it can request the region
and not release it. But as long as we don't have that, I agree with
Milton that the individual drivers should temporarily request the
Super-I/O region before accessing it.
--
Jean Delvare
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Hans de Goede @ 2008-07-11 7:27 UTC (permalink / raw)
To: Jean Delvare
Cc: linuxppc-dev, Samuel Ortiz, linux-kernel, Milton Miller,
lm-sensors
In-Reply-To: <20080711085246.1ead773b@hyperion.delvare>
Jean Delvare wrote:
> Hi Hans, hi Milton,
>
<snip>
>> One could make a superio driver, and create sub-devices for the IR,
>> I2C, floppy, parallel, etc
>> nodes.
>
> There have been proposals to do this, and this would indeed be a very
> good idea, but unfortunately nobody took the time to implement this
> properly, push it upstream and volunteer to maintain it. The problem is
> that you don't need just a "driver", but a new subsystem, that needs to
> be designed and maintained.
>
Well, I believe there have been some lightweight superio locking coordinator
patches been floating around on the lm_sensors list, and I have reviewed them
and then a new version was done with my issues fixed.
I kinda liked the proposed solution there, it was quite simple, moved all the
generic superio stuff into generic superio code, and added locking for super io
access from multiple drivers, what ever happened to those patches?
If were to start using those, we could actually do a request region and then
never release it, as things should be.
Regards,
Hans
^ permalink raw reply
* Re: Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
From: Arnd Bergmann @ 2008-07-11 7:02 UTC (permalink / raw)
To: linuxppc-dev; +Cc: prodyut hazarika
In-Reply-To: <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com>
On Friday 11 July 2008, prodyut hazarika wrote:
> I have a version which just keeps a count of bytes copied till any
> fault happened. Then for any exception, I just substract this value
> from the total number of bytes to be copied, and store in r3 and
> return back. This is the common fixup code for all paths. It makes the
> fixup code much more readable like other architectures (eg. x86).
In some cases, you need to make sure that the return value is exactly
the maximum you could copy, not a little less.
> The current code tries to copy one byte at a time after read fault. I
> don't understand why that is necessary. It then clears out the
> destination. All these logic has made the code very unfriendly to
> read.
I'm not sure if the code is also avoiding unaligned accesses here,
which is not a problem on x86. If you access uncached memory with
unaligned pointers, you get an exception and the fixup code will
copy it just fine with byte accesses.
> 2) For read failure, why do we clear out the destination (lines 509 to
> 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that.
All architectures should do that for copy_from_user, to avoid potential
data leaks from the kernel when the data is copied back.
Arnd <><
^ permalink raw reply
* Re: mpc744x, Marvell mv6446x kernel guidance please
From: Marco Stornelli @ 2008-07-11 7:01 UTC (permalink / raw)
To: Stephen Horton; +Cc: linuxppc-embedded
In-Reply-To: <295C5089A56CE143B316E5F67CA99CB001C9E4BD@cowboy.inovate.inovate.com>
Stephen Horton ha scritto:
> Hello folks,
>
> In a current work project, I have inherited a compactPCI board that has
> an mpc7447/7448 powerpc processor as well as a Marvell system
> controller, model mv64462 (stripped down mv64460). The board has a
> somewhat working Gentoo Linux port running on it from long ago and a
> company far far away (kernel version 2.6.9 built using arch/ppc). To
> prepare for an upcoming deployment, I would like to bring the OS
> up-to-date on this board with a newer kernel (targeting Gentoo 2008),
> but I am unsure of the approach to take. I am a software developer, but
> normally do not work on kernel porting / board integration. I have
> researched the arch/ppc to arch/powerpc migration, but I'm a bit
> intimidated by the 'new' device tree symantics and other changes to the
> stream. Here are some questions:
>
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
> 3. Any advice of any kind?
>
> Regards,
>
> Stephen
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 1. Is it possible with the 2.6.24 (Gentoo 2008) kernel to still use
> arch/ppc for this platform architecture? I've tried to get this to
> compile, but am having trouble with files from arch/powerpc getting
> pulled in; then I read some comments (from I believe this forum) that
> indicated that arch/ppc is not longer supposed to compile
Good idea, I suggest you to use arch/powerpc, arch/ppc won't be
supported in the future and this folder there won't be anymore!
> 2. Does anyone have example code for this platform architecture?
> Any freebees I could use for creating my device tree?
I suggest you to use, as starting point, a dts file for a board similar
to your board, I don't know if your board is somehow derived from one
evaluation board.
> 3. Any advice of any kind?
First of all read the kernel documentation about dts in the powerpc
folder. You can find in that documentation even some reference to the
open-firmware standard (IEEE 1275).
Last suggestions, I wouldn't use Gentoo Linux but a specific embedded
distribution, for example ELDK.
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* linux boot sequence
From: Rami WEHBI @ 2008-07-11 6:34 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 600 bytes --]
Hi all,
I am using the ppc405 and I would like to know, how does linux on this architect detect the available memory size in details !!!
is it a parameter passed to linux at startup by the boot loader ??
is it an automatic detection ?? what are the steps to accomplish this job then ???
Best regards to all,
Rami
Rami WEHBI
Recherche & Développement
Tél : +33 2 36 56 86 00
Fax : +33 2 36 56 86 01
www.wirecom-tech.com
<http://www.wirecom-tech.com>
WIRECOM Technologies
135, Rue Jacques Charles
45166 Olivet
[-- Attachment #1.2: Type: text/html, Size: 5158 bytes --]
[-- Attachment #2: logo_officiel_151.gif --]
[-- Type: image/gif, Size: 3370 bytes --]
[-- Attachment #3: confidentialite.gif --]
[-- Type: image/gif, Size: 8184 bytes --]
[-- Attachment #4: arbre-logo.gif --]
[-- Type: image/gif, Size: 2808 bytes --]
^ permalink raw reply
* Re: [RFC] (almost) booting allyesconfig -- please don't poke super-io without request_region
From: Jean Delvare @ 2008-07-11 6:52 UTC (permalink / raw)
To: Milton Miller
Cc: Ortiz, Samuel, linux-kernel, lm-sensors, linuxppc-dev,
Hans de Goede
In-Reply-To: <acca8e14e769b2feadee19f1f7448438@bga.com>
Hi Hans, hi Milton,
On Thu, 10 Jul 2008 16:51:33 -0500, Milton Miller wrote:
>
> On Jul 10, 2008, at 4:33 PM, Hans de Goede wrote:
>
> > Milton Miller wrote:
> >> After the following patch to mark the isa region busy and applying a
> >> few
> >> patches[1], I was able to kexec boot into an all-yes-config kernel
> >> from linux-next, with the following KCONFIG_ALLCONFIG file:
> ...
> >> While the first two might not be required, and the third is just
> >> selecting the right platform, it would be nice to get the drivers
> >> to play as well as the rest of the kernel.
> >> The drivers all are for super-io chips, either irda/FIR drivers or
> >> hwmon,
> >> and poke at isa ports without checking request_region.
> >
> > Erm,
> >
> > The superio sensor drivers only poke the superio chip registers
> > without request region during the probe phase, iow they try to detect
> > the chip, using a widely document and standardized (part of isa pnp
> > AFAIK) procedure on standardized ports.
> >
> > Let me try to explain a bit about superio chips, they have 2 superio
> > control registers (an index and data register) with which things like
> > a manufacturer and device id can be read, besides these id registers
> > they also have a set of registers with config for different logical
> > devices. Once the id is matched, the driver knows which logical device
> > config to read, reads a (different) isa base address + range from the
> > logical device config, and then does a request_region on the region
> > actually used by the logical device.
> >
> > The superio control registers are thus a sort of pci configuration
> > space if you want, doing a request_region on these is not such a good
> > idea, as multiple drivers (for different logical devices within the
> > superio device) may use these, so trying to gain exclusive access will
> > lead to troubles.
> >
> > I hope with this info about the problem space, that you maybe have a
> > suggestion on howto fix this?
>
> My point is that they are probing without even knowing that a such a IO
> range exists.
>
> These are the only drivers left in the tree that still do this. (At
> least that are not
> blocked on a powerpc allyesconfig for 64-bit, !CONFIG_VIRT_TO_BUS).
I guess we could make all these drivers depend on X86, I suspect that
these chips are only used in PCs?
> One could make a superio driver, and create sub-devices for the IR,
> I2C, floppy, parallel, etc
> nodes.
There have been proposals to do this, and this would indeed be a very
good idea, but unfortunately nobody took the time to implement this
properly, push it upstream and volunteer to maintain it. The problem is
that you don't need just a "driver", but a new subsystem, that needs to
be designed and maintained.
> I would even accept a check_region (horrors!), it would impove the
> situation.
>
> But most other drivers do this by request_region, probe, then release
> the region afterwards.
I agree that the hwmon drivers should do this, as long as no superio
subsystem exist. This should solve the problem at hand and might even
help spot bad drivers which use the configuration space for longer than
initialization time.
> Besides, one could argue the superio region should be requested while
> probing, to prevent other cpus from poking at the super io chip at the
> same time. Think of it as missing locking.
Agreed.
Milton, care to submit a patch fixing the affected hwmon drivers?
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: Making __copy_tofrom_user more readable for powerpc (arch/powerpc/lib/copy_32.S)
From: Michael Neuling @ 2008-07-11 6:50 UTC (permalink / raw)
To: prodyut hazarika; +Cc: linuxppc-dev
In-Reply-To: <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com>
In message <49c0ff980807101644x6ffb9a66x3f73c72f1be86e3@mail.gmail.com> you wro
te:
> Hi all,
> I am trying to optimize the __copy_tofrom_user function for PPC4xx,
> and I would want to know why the exception handling code has been made
> so complicated. All the fixup code should do is to store the number of
> bytes that failed in copy in r3 and return back.
>
> The current code tries to copy one byte at a time after read fault. I
> don't understand why that is necessary. It then clears out the
> destination. All these logic has made the code very unfriendly to
> read.
Would a multibyte read be guaranteed to be aligned?
> I have a version which just keeps a count of bytes copied till any
> fault happened. Then for any exception, I just substract this value
> from the total number of bytes to be copied, and store in r3 and
> return back. This is the common fixup code for all paths. It makes the
> fixup code much more readable like other architectures (eg. x86).
>
> My questions are:
> 1) Why do we need to distinguish between load and store failure? If
> either load or store fails, the copy did not go thru. But the code
> sets r9 to 0 for load failure, and r9 to 1 for write failure. Why do
> we need to care for that?
>
> 2) For read failure, why do we clear out the destination (lines 509 to
> 529 in arch/powerpc/lib/copy_32.S)? Other architecture don't do that.
Which version of the code are you referring to here? Can you give us a
git SHA1?
Clean up patches are welcome. Maybe it would be best to post what you
have as an RFC patch. Then people can take a closer/easier look at your
cleanups and/or try them out.
Mikey
>
> I would appreciate any comments.
>
> Thanks,
> Prodyut
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCH -next-20080709] fixup stop_machine use cpu mask vs ftrace
From: Rusty Russell @ 2008-07-11 6:43 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev, linux-next, Ingo Molnar, linux-kernel
In-Reply-To: <for-27-patch0-1@bga.com>
On Friday 11 July 2008 07:07:57 Milton Miller wrote:
> Hi Rusty, Ingo.
>
> Rusty's patch [PATCH 3/3] stop_machine: use cpu mask rather than magic
> numbers didn't find kernel/trace/ftrace.c in -next, causing an immediate
> almost NULL pointer dereference in ftrace_dynamic_init.
Yes, I'm switching the patches around, so it does the transition correctly.
Introduces a new stop_machine() fn with the new interface and deprecates the
old stop_machine_run(). We can remove stop_machine_run() after everyone is
switched.
Thanks,
Rusty.
^ 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