Re: [PATCH] xmon consistency clean up
On Wed, 2007-07-25 at 11:57 +0900, Ishizaki Kou wrote:
This patch cleans up xmon to keep consistency.
In xmon, we should use console I/O functions that are named the same
as user space stdio functions. But commit
4d404edce30f911004850d472e05a31efd751662 broke this consistency.
Signed-off-by: Kou Ishizaki [EMAIL PROTECTED]
---
Index: linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
===
--- linux-powerpc-git.orig/arch/powerpc/xmon/nonstdio.c
+++ linux-powerpc-git/arch/powerpc/xmon/nonstdio.c
@@ -133,7 +133,7 @@ void xmon_printf(const char *format, ...
xmon_write(xmon_outbuf, n);
}
-void xmon_puts(const char *str)
+void xmon_fputs(const char *str)
{
xmon_write(str, strlen(str));
Nah, keep it xmon_puts, since it doesn't take a stream argument and
define a puts for use by xmon core.
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Pegasos keyboard detection
On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote: As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller on the PegasosPPC. This is because of a feature/bug in the OF device tree: the device_type attribute is an empty string instead of 8042 as the kernel expects. This patch (against 2.6.22.1) adds a secondary detection which looks for a device whose *name* is 8042 if there is no device whose *type* is 8042. Signed-off-by: Alan Curry [EMAIL PROTECTED] Doesn't it have something in compatible instead ? that would be the way to go. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Please pull from 'for_paulus' branch
On Tue, 2007-07-24 at 05:01, Kumar Gala wrote: Please pull from 'for_paulus' branch of master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for_paulus Sorry I wasn't able to get this pull request out before -rc1 got released, but had some issues w/accessing email/accounts this weekend. to receive the following updates: Could you help to pick up the 7448hpc2 cuboot support patch: http://ozlabs.org/pipermail/linuxppc-dev/2007-July/038952.html Roy ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Pegasos keyboard detection
Benjamin Herrenschmidt writes the following: Doesn't it have something in compatible instead ? that would be the way to go. Assuming that would be represented as a file named compatible in the directory /proc/device-tree/*/*/[EMAIL PROTECTED] ... no, it doesn't have one of those. For the amusement of all, I offer the entire device-tree as presented in /proc by my running 2.6.22.1 kernel. Available for a limited time from http://world.std.com/~pacman/pegasosII_proc_device-tree.tar.gz -- Alan Curry [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Attempt at addressing head*.S for modpost warnings
Stephen,
Paul said you were looking into this issue as well. Wanted to post what I
did on ppc32/e500 as a start for you to look at. I think the other ppc32
head*.S can follow the same pattern if we like this. However, wasn't sure
how to do _ENTRY() for ppc64.
- k
diff --git a/arch/powerpc/kernel/head_fsl_booke.S
b/arch/powerpc/kernel/head_fsl_booke.S
index 1f155d3..d83cbbb 100644
--- a/arch/powerpc/kernel/head_fsl_booke.S
+++ b/arch/powerpc/kernel/head_fsl_booke.S
@@ -52,9 +52,9 @@
* r7 - End of kernel command line string
*
*/
- .text
-_GLOBAL(_stext)
-_GLOBAL(_start)
+ .section.text.head, ax
+_ENTRY(_stext);
+_ENTRY(_start);
/*
* Reserve a word at a fixed location to store the address
* of abatron_pteptrs
diff --git a/arch/powerpc/kernel/vmlinux.lds.S
b/arch/powerpc/kernel/vmlinux.lds.S
index 0c45855..823a8cb 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -34,6 +34,8 @@ SECTIONS
/* Text and gots */
.text : {
+ ALIGN_FUNCTION();
+ *(.text.head)
_text = .;
TEXT_TEXT
SCHED_TEXT
diff --git a/include/asm-powerpc/ppc_asm.h b/include/asm-powerpc/ppc_asm.h
index fa083d8..7ec22d2 100644
--- a/include/asm-powerpc/ppc_asm.h
+++ b/include/asm-powerpc/ppc_asm.h
@@ -183,6 +183,11 @@ GLUE(.,name):
#else /* 32-bit */
+#define _ENTRY(n) \
+ .stabs __stringify(n:F-1),N_FUN,0,0,n;\
+ .globl n; \
+n:
+
#define _GLOBAL(n) \
.text; \
.stabs __stringify(n:F-1),N_FUN,0,0,n;\
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [PATCH 1/3] Add a new member name to structure irq_host
Hi, Ben, Thanks! Sure, hence the word 'optional' which would provide a default name. About the default name, since platforms we touched are very limited, we do not know which name should be proper default name. We just assign those default name to 'NULL' for passing the compiling process. And the platform maintain can correct it. Cheers! Wei. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Pegasos keyboard detection
On Tue, 2007-07-24 at 21:28 -0400, Alan Curry wrote:
As of 2.6.22 the kernel doesn't recognize the i8042 keyboard/mouse controller
on the PegasosPPC. This is because of a feature/bug in the OF device tree:
the device_type attribute is an empty string instead of 8042 as the
kernel expects. This patch (against 2.6.22.1) adds a secondary detection
which looks for a device whose *name* is 8042 if there is no device whose
*type* is 8042.
Signed-off-by: Alan Curry [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Note, if there's a volunteer, we could probably turn that code into a
nice table lookup.
Cheers,
Ben.
--- arch/powerpc/kernel/setup-common.c.orig 2007-07-24 19:04:17.0
-0500
+++ arch/powerpc/kernel/setup-common.c2007-07-24 19:06:36.0
-0500
@@ -487,6 +487,10 @@ int check_legacy_ioport(unsigned long ba
switch(base_port) {
case I8042_DATA_REG:
np = of_find_node_by_type(NULL, 8042);
+ /* Pegasos has no device_type on its 8042 node, look for the
+ * name instead */
+ if (!np)
+ np = of_find_node_by_name(NULL, 8042);
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, fdc);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
modpost warning question
I'm seeing the following warning:
WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to
.exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
I don't understand why its not ok to access .exit.text from .init.text
The following addresses the issue, however I don't particularly like it:
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index ac3596f..100bf41 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -245,7 +245,7 @@ int __init gfar_mdio_init(void)
return driver_register(gianfar_mdio_driver);
}
-void __exit gfar_mdio_exit(void)
+void gfar_mdio_exit(void)
{
driver_unregister(gianfar_mdio_driver);
}
diff --git a/drivers/net/gianfar_mii.h b/drivers/net/gianfar_mii.h
index 5d34004..b373091 100644
--- a/drivers/net/gianfar_mii.h
+++ b/drivers/net/gianfar_mii.h
@@ -42,5 +42,5 @@ struct gfar_mii {
int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum);
int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int __init gfar_mdio_init(void);
-void __exit gfar_mdio_exit(void);
+void gfar_mdio_exit(void);
#endif /* GIANFAR_PHY_H */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: modpost warning question
On Wed, Jul 25, 2007 at 02:14:12AM -0500, Kumar Gala wrote: I'm seeing the following warning: WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init') I don't understand why its not ok to access .exit.text from .init.text Several architectures discards .exit.text in the final linker script (arch/$(ARCH)/kernel/vmlinux.lds.S So any references to .exit.text will when a module is build-in result in a linker error because ld will flag it as an error when we reference a symbol in a discarded section. For the popular architectures (i386,x86_64) we discard .exit.text at runtime so here we do not see the error from ld (sadly). Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: modpost warning question
On Jul 25, 2007, at 2:27 AM, Sam Ravnborg wrote: On Wed, Jul 25, 2007 at 02:14:12AM -0500, Kumar Gala wrote: I'm seeing the following warning: WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init') I don't understand why its not ok to access .exit.text from .init.text Several architectures discards .exit.text in the final linker script (arch/$(ARCH)/kernel/vmlinux.lds.S So any references to .exit.text will when a module is build-in result in a linker error because ld will flag it as an error when we reference a symbol in a discarded section. For the popular architectures (i386,x86_64) we discard .exit.text at runtime so here we do not see the error from ld (sadly). Fair point, wondering what we do with .exit on PPC, another thing for the list :) - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: modpost warning question
On Wed, 2007-07-25 at 02:14 -0500, Kumar Gala wrote: I'm seeing the following warning: WARNING: vmlinux.o(.init.text+0x1acdc): Section mismatch: reference to .exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init') I don't understand why its not ok to access .exit.text from .init.text The following addresses the issue, however I don't particularly like it: Because exit.text is removed when compiling built-in Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: do section mismatch check on full vmlinux breaks powerpc build
On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote: Hello- 2.6.23-rc1 breaks the build for 64-bit powerpc for me (using maple_defconfig): LD vmlinux.o powerpc64-unknown-linux-gnu-ld: dynreloc miscount for kernel/built-in.o, section .opd powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 This is on a i386 host with: powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.2 GNU ld version 2.16.1 Reverting the following commit fixes it: commit 741f98fe298a73c9d47ed53703c1279a29718581 Author: Sam Ravnborg [EMAIL PROTECTED] Date: Tue Jul 17 10:54:06 2007 +0200 kbuild: do section mismatch check on full vmlinux However, I see a possibly related binutils patch: http://article.gmane.org/gmane.comp.gnu.binutils/33650 Will there be a kbuild fix for this or should I update my binutils? What kbuild does is a very basic link of a number of .o files. Why this suddenly breaks I do not fully understand and I see no obvious way to fix it in kbuild. And browsing arch/ppc/kernel/vmlinux.lds.S I see no special handling of .opd. Puzzeled? I'm not sure how to deal with this one. Would prefer to say that this is a binutils bug so fix it there but then I like to provide a workaround for those with faulty toolchains. I could put the link and the additional modpost check inside a CONFIG_SOMETHING Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: do section mismatch check on full vmlinux breaks powerpc build
On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote: Hello- 2.6.23-rc1 breaks the build for 64-bit powerpc for me (using maple_defconfig): LD vmlinux.o powerpc64-unknown-linux-gnu-ld: dynreloc miscount for kernel/built-in.o, section .opd powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 This is on a i386 host with: powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.2 GNU ld version 2.16.1 Reverting the following commit fixes it: commit 741f98fe298a73c9d47ed53703c1279a29718581 Author: Sam Ravnborg [EMAIL PROTECTED] Date: Tue Jul 17 10:54:06 2007 +0200 kbuild: do section mismatch check on full vmlinux However, I see a possibly related binutils patch: http://article.gmane.org/gmane.comp.gnu.binutils/33650 Will there be a kbuild fix for this or should I update my binutils? Did a bit more testing. Im am down to the following to reproduce the fault: /opt/crosstool/gcc-4.1.0-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld -m elf64ppc -r -o vmlinux.o kernel/signal.o arch/powerpc/kernel/vdso.o Seems that vdso.o and signal.o does not like each other?? Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: do section mismatch check on full vmlinux breaks powerpc build
On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote: Hello- 2.6.23-rc1 breaks the build for 64-bit powerpc for me (using maple_defconfig): LD vmlinux.o powerpc64-unknown-linux-gnu-ld: dynreloc miscount for kernel/built-in.o, section .opd powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 This is on a i386 host with: powerpc64-unknown-linux-gnu-gcc (GCC) 4.1.2 GNU ld version 2.16.1 Reverting the following commit fixes it: commit 741f98fe298a73c9d47ed53703c1279a29718581 Author: Sam Ravnborg [EMAIL PROTECTED] Date: Tue Jul 17 10:54:06 2007 +0200 kbuild: do section mismatch check on full vmlinux However, I see a possibly related binutils patch: http://article.gmane.org/gmane.comp.gnu.binutils/33650 Will there be a kbuild fix for this or should I update my binutils? I tried searching a bit more to find the culprint. I narrowed it down to the following change to avoid the breakage: diff --git a/include/linux/mm.h b/include/linux/mm.h index c456c3a..2ea222f 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1246,7 +1246,7 @@ void drop_slab(void); extern int randomize_va_space; #endif -__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); +//__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); #endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ So seems that something goes a bit fishy when using weak symbols and this trigges a binutils bug. The above line was introdused in the following commit: commit f269fdd1829acc5e53bf57b145003e5733133f2b Author: David Howells [EMAIL PROTECTED] Date: Wed Sep 27 01:50:23 2006 -0700 [PATCH] NOMMU: move the fallback arch_vma_name() to a sensible place Move the fallback arch_vma_name() to a sensible place (kernel/signal.c). Currently it's in fs/proc/task_mmu.c, a file that is dependent on both CONFIG_PROC_FS and CONFIG_MMU being enabled, but it's used from kernel/signal.c from where it is called unconditionally. [EMAIL PROTECTED]: build fix] Signed-off-by: David Howells [EMAIL PROTECTED] Signed-off-by: Andrew Morton [EMAIL PROTECTED] Signed-off-by: Linus Torvalds [EMAIL PROTECTED] Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.23-rc1 breaks on JS20 w/SLOF
On Tue, Jul 24, 2007 at 08:06:18AM +1000, Benjamin Herrenschmidt wrote: On Mon, 2007-07-23 at 16:47 +0200, Adrian Reber wrote: On a JS20 with SLOF (pretending to be Maple) 2.6.23-rc1 breaks with following oops. 2.6.22 is working. Let me know if I can help debug this. That would be my fault... looks like it tries to access IO ports before the IO space is mapped by the PCI code, and without a legacy ISA range. The later is now the only case where IO ports are available before the main PCI setup. I can add some tweak to the maple code to map the ISA stuff even when the isa node is missing... This also happens on JS21 (with SLOF) in a pretty similar way. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/5] Invert null match behaviour for irq_hosts
Currently if you don't specify a match callback for your irq_host it's
assumed you match everything. This is a kind of opt-out approach, and
turns out to be the exception rather than the rule.
So change the semantics to be opt-in, ie. you don't match anything unless
you provide a match callback. This in itself isn't very useful, but will
allow us to provide a default match implementation in a subsequent patch.
Signed-off-by: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/kernel/irq.c |2 +-
arch/powerpc/platforms/celleb/interrupt.c |7 +++
arch/powerpc/platforms/iseries/irq.c |7 +++
arch/powerpc/platforms/ps3/interrupt.c|7 +++
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 31d1de7..88e6b59 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -523,7 +523,7 @@ struct irq_host *irq_find_host(struct device_node *node)
*/
spin_lock_irqsave(irq_big_lock, flags);
list_for_each_entry(h, irq_hosts, link)
- if (h-ops-match == NULL || h-ops-match(h, node)) {
+ if (h-ops-match != NULL h-ops-match(h, node)) {
found = h;
break;
}
diff --git a/arch/powerpc/platforms/celleb/interrupt.c
b/arch/powerpc/platforms/celleb/interrupt.c
index 4ecdf06..c7c68ca 100644
--- a/arch/powerpc/platforms/celleb/interrupt.c
+++ b/arch/powerpc/platforms/celleb/interrupt.c
@@ -175,11 +175,18 @@ static int beatic_pic_host_xlate(struct irq_host *h,
struct device_node *ct,
return 0;
}
+static int beatic_pic_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops beatic_pic_host_ops = {
.map = beatic_pic_host_map,
.remap = beatic_pic_host_remap,
.unmap = beatic_pic_host_unmap,
.xlate = beatic_pic_host_xlate,
+ .match = beatic_pic_host_match,
};
/*
diff --git a/arch/powerpc/platforms/iseries/irq.c
b/arch/powerpc/platforms/iseries/irq.c
index 3666746..701d929 100644
--- a/arch/powerpc/platforms/iseries/irq.c
+++ b/arch/powerpc/platforms/iseries/irq.c
@@ -346,8 +346,15 @@ static int iseries_irq_host_map(struct irq_host *h,
unsigned int virq,
return 0;
}
+static int iseries_irq_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops iseries_irq_host_ops = {
.map = iseries_irq_host_map,
+ .match = iseries_irq_host_match,
};
/*
diff --git a/arch/powerpc/platforms/ps3/interrupt.c
b/arch/powerpc/platforms/ps3/interrupt.c
index 30b9f4c..3a6db04 100644
--- a/arch/powerpc/platforms/ps3/interrupt.c
+++ b/arch/powerpc/platforms/ps3/interrupt.c
@@ -673,9 +673,16 @@ static int ps3_host_map(struct irq_host *h, unsigned int
virq,
return 0;
}
+static int ps3_host_match(struct irq_host *h, struct device_node *np)
+{
+ /* Match all */
+ return 1;
+}
+
static struct irq_host_ops ps3_host_ops = {
.map = ps3_host_map,
.unmap = ps3_host_unmap,
+ .match = ps3_host_match,
};
void __init ps3_register_ipi_debug_brk(unsigned int cpu, unsigned int virq)
--
1.5.1.3.g7a33b
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
About mdio_bus for 82xx based board
Hi all, I'm trying to make FCC ethernet work with my board, based on an MPC8275 processor. I'm using kernel 2.6.22.1 I have the following problems: 1) When mdiobus_register() called from mii-bitbang.c (fs_enet_mdio_probe() function) attemps to do a device_register for the mdio bus, it actually registers the device with a bus_id in the form [0|1|...]:phy_addr, that is the first part a simple integer. This, of course, happens because fs_enet_of_init() (fsl_soc.c) does a platform_device_register_simple(fsl-bb-mdio, i, NULL, 0); with i being the first part of the bus, starting from 0. Unfortunately, when fs_init_phy() (fs_enet_main.c) calls phy_connect() and therefore phy_attach() (phy_device.c), the latter attempts to find the device in the mdio bus, but it searches using the bus_id registered in the net_device struct, which is in the form of resource address:phy_addr, eg. f000:0, and therefore it fails... I don't know if I am doing something wrong here, so any hint would be greatly appreciated. 2) Since there are two ethernet@address nodes in my device tree, fs_of_enet_init() calls platform_device_register_simple(fsl-bb-mdio,...) twice, therefore creating two mdio busses, 0 and 1, each having the same two devices. For example, if I have two PHYs with addresses 1 and 5, I will get two mdio busses and 4 devices, 0:1, 0:5, 1:1 and 1:5. Well, this doesn't sound right to me, although I am not sure if this is a fatal issue. Any comments? 3) Also, if I don't want to enter the phy interrupt in the device tree (there is not one or I want to use PHY_POLL), what should I do? dtc seems to not allow -1 as a value in the reg property. thank you in advance for your responses Alex ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] Fix ibmvscsi client for multiplatform iSeries+pSeries kernel.
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
--- linux-2.6.19.ppc64/drivers/scsi/ibmvscsi/rpa_vscsi.c~ 2006-11-29
21:57:37.0 +
+++ linux-2.6.19.ppc64/drivers/scsi/ibmvscsi/rpa_vscsi.c2006-12-19
15:42:57.0 +
@@ -42,14 +42,14 @@ static unsigned int partition_number = -
* Routines for managing the command/response queue
*/
/**
- * ibmvscsi_handle_event: - Interrupt handler for crq events
+ * rpavscsi_handle_event: - Interrupt handler for crq events
* @irq: number of irq to handle, not used
* @dev_instance: ibmvscsi_host_data of host that received interrupt
*
* Disables interrupts and schedules srp_task
* Always returns IRQ_HANDLED
*/
-static irqreturn_t ibmvscsi_handle_event(int irq, void *dev_instance)
+static irqreturn_t rpavscsi_handle_event(int irq, void *dev_instance)
{
struct ibmvscsi_host_data *hostdata =
(struct ibmvscsi_host_data *)dev_instance;
@@ -66,9 +66,9 @@ static irqreturn_t ibmvscsi_handle_event
* Frees irq, deallocates a page for messages, unmaps dma, and unregisters
* the crq with the hypervisor.
*/
-void ibmvscsi_release_crq_queue(struct crq_queue *queue,
- struct ibmvscsi_host_data *hostdata,
- int max_requests)
+static void rpavscsi_release_crq_queue(struct crq_queue *queue,
+ struct ibmvscsi_host_data *hostdata,
+ int max_requests)
{
long rc;
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -108,12 +108,13 @@ static struct viosrp_crq *crq_queue_next
}
/**
- * ibmvscsi_send_crq: - Send a CRQ
+ * rpavscsi_send_crq: - Send a CRQ
* @hostdata: the adapter
* @word1: the first 64 bits of the data
* @word2: the second 64 bits of the data
*/
-int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64
word2)
+static int rpavscsi_send_crq(struct ibmvscsi_host_data *hostdata,
+u64 word1, u64 word2)
{
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -121,10 +122,10 @@ int ibmvscsi_send_crq(struct ibmvscsi_ho
}
/**
- * ibmvscsi_task: - Process srps asynchronously
+ * rpavscsi_task: - Process srps asynchronously
* @data: ibmvscsi_host_data of host
*/
-static void ibmvscsi_task(void *data)
+static void rpavscsi_task(void *data)
{
struct ibmvscsi_host_data *hostdata = (struct ibmvscsi_host_data *)data;
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -189,6 +190,42 @@ static void set_adapter_info(struct ibmv
}
/**
+ * reset_crq_queue: - resets a crq after a failure
+ * @queue: crq_queue to initialize and register
+ * @hostdata: ibmvscsi_host_data of host
+ *
+ */
+static int rpavscsi_reset_crq_queue(struct crq_queue *queue,
+ struct ibmvscsi_host_data *hostdata)
+{
+ int rc;
+ struct vio_dev *vdev = to_vio_dev(hostdata-dev);
+
+ /* Close the CRQ */
+ do {
+ rc = plpar_hcall_norets(H_FREE_CRQ, vdev-unit_address);
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
+
+ /* Clean out the queue */
+ memset(queue-msgs, 0x00, PAGE_SIZE);
+ queue-cur = 0;
+
+ set_adapter_info(hostdata);
+
+ /* And re-open it again */
+ rc = plpar_hcall_norets(H_REG_CRQ,
+ vdev-unit_address,
+ queue-msg_token, PAGE_SIZE);
+ if (rc == 2) {
+ /* Adapter is good, but other end is not ready */
+ printk(KERN_WARNING ibmvscsi: Partner adapter not ready\n);
+ } else if (rc != 0) {
+ printk(KERN_WARNING
+ ibmvscsi: couldn't register crq--rc 0x%x\n, rc);
+ }
+ return rc;
+}
+/**
* initialize_crq_queue: - Initializes and registers CRQ with hypervisor
* @queue: crq_queue to initialize and register
* @hostdata: ibmvscsi_host_data of host
@@ -197,9 +234,9 @@ static void set_adapter_info(struct ibmv
* the crq with the hypervisor.
* Returns zero on success.
*/
-int ibmvscsi_init_crq_queue(struct crq_queue *queue,
- struct ibmvscsi_host_data *hostdata,
- int max_requests)
+static int rpavscsi_init_crq_queue(struct crq_queue *queue,
+ struct ibmvscsi_host_data *hostdata,
+ int max_requests)
{
int rc;
int retrc;
@@ -226,7 +263,7 @@ int ibmvscsi_init_crq_queue(struct crq_q
queue-msg_token, PAGE_SIZE);
if (rc == H_RESOURCE)
/* maybe kexecing and resource is busy. try a reset */
-
Re: dtc: Improve the make install target
So, like, the other day David Gibson mumbled: This patch makes various improvements to dtc's make install target: - libfdt is also installed. Specifically, libfdt.a and the two export relevant header files, fdt.h and libfdt.h are installed. - ftdump is no longer installed. It was only ever a development debugging tool and may well go away at some point. - In keeping with normal conventions, there is now a PREFIX variable, allowing control of where things are installed (in /usr, /usr/local, /opt, etc.). - By default, installed into the user's home directory, instead of /usr. This is friendlier for self-installers, package builders can easily override PREFIX to restore the old behaviour. Signed-off-by: David Gibson [EMAIL PROTECTED] Applied. Thanks, jdl ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] [POWERPC] Remove dummy network phy from MPC8313E-RDB
Cleaned up inexistent network phy from the target dts, added
necessary property to gianfar node there.
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
---
arch/powerpc/boot/dts/mpc8313erdb.dts |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8313erdb.dts
b/arch/powerpc/boot/dts/mpc8313erdb.dts
index a1533cc..b602a8b 100644
--- a/arch/powerpc/boot/dts/mpc8313erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8313erdb.dts
@@ -98,12 +98,6 @@
reg = 24520 20;
#address-cells = 1;
#size-cells = 0;
- phy1: [EMAIL PROTECTED] {
- interrupt-parent = ipic ;
- interrupts = 13 8;
- reg = 1;
- device_type = ethernet-phy;
- };
phy4: [EMAIL PROTECTED] {
interrupt-parent = ipic ;
interrupts = 14 8;
@@ -120,7 +114,7 @@
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 25 8 24 8 23 8;
interrupt-parent = ipic ;
- phy-handle = phy1 ;
+ fixed_speed = 1 1000;
};
[EMAIL PROTECTED] {
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
On Jul 25, 2007, at 11:53 AM, Vitaly Bordug wrote: This is now very similar to pata_platform.c, they both use same platform data structure and same resources. To achieve that, byte_lanes_swapping platform data variable and platform specified iops removed from that driver. It's fine, since those were never used anyway. pata_platform and ide_platform are carrying same driver names, to easily switch between these drivers, without need to touch platform code. Signed-off-by: Anton Vorontsov [EMAIL PROTECTED] Signed-off-by: Vitaly Bordug [EMAIL PROTECTED] Out of interest is this something that could exist in pata land? I haven't really been following legacy/ide vs pata lately. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
Hi, I've ported myri10ge to use the new LRO interface. I have attached a preliminary patch to myri10ge. I'm very pleased to note that the performance is on-par with my own LRO used by our out-of-tree driver. (except when using mixed MTUS, see performance data below). As I expected, actually porting our driver to use the LRO interface gave me a far better understanding of the interface, and allowed for better feedback. I have attached a patch to the LRO code which addresses some of the issues I mention below. Please find below a performance summary, as well as my comments on the LRO code, and patches to myri10ge and inet_lro. Both patches are Signed-off-by: Andrew J. Gallatin [EMAIL PROTECTED] Cheers, Drew === Performance: === Here is a performance summary taken on my very low-end 2.0GHz AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ running 2.6.23-rc1 and receiving a netperf TCP_SENDFILE test from an identical sender (which was running 2.6.22 and our 1.3.1 out of tree driver). The netserver process was bound to a different core than the interrupt handler. The data reported is from the median of 5 60 second netperf tests. The following settings were in /etc/sysctl.conf on both machines: net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.core.netdev_max_backlog = 2500 net.ipv4.tcp_timestamps = 0 RX Performance for Sender MTU=1500, Receiver MTU=1500 expressed as x Gb/s, y %CPU receiver utilization: rxbuf(1) 1.3.1(2) inet_lro no LRO ---- --- 4K pg8.9 78% 8.8 77% 3.7 89% 8K pg9.2 77% 9.1 77% 3.7 89% 16Kpg9.4 73% 9.4 73% 3.8 89% 32Kpg9.4 72% 9.4 72% 3.9 89% skb N/A N/A 5.5 90% 4.1 92% RX Performance for Sender MTU=1500, Receiver MTU=9000 expressed as x Gb/s, y %CPU receiver utilization: rxbuf(1) 1.3.1(2) inet_lro no LRO ---- --- 4K pg8.9 78% 7.3 79% 3.7 89% 8K pg9.2 77% 7.6 79% 3.7 89% 16Kpg9.4 73% 8.0 78% 3.8 89% 32Kpg9.4 72% 8.2 79% 3.9 89% skb N/A N/A 4.9 92% 4.1 92% RX Performance for Sender MTU=9000, Receiver MTU=9000 expressed as x Gb/s, y %CPU receiver utilization: rxbuf(1) 1.3.1(2) inet_lro no LRO ---- --- 4K pg9.9 63% 9.6 66% 8.3 71% 8K pg9.9 60% 9.9 63% 8.4 72% 16Kpg9.9 55% 9.9 55% 8.7 70% 32Kpg9.9 53% 9.9 53% 8.9 67% skb N/A N/A 9.9 68% 8.7 72% (1) xK pg means the driver was configured to adjust the receive page size using MYRI10GE_ALLOC_ORDER. skb means an internal variant of our driver which receives into skbs rather than pages was used. (2) 1.3.1 is our latest out of tree driver which uses the myri10ge specific frags-based LRO code previously submitted and rejected. === Code review / comments: === 1) Checksum information for CHECKSUM_COMPLETE drivers. Our NIC passes partial checksums to our driver. In the current code, it seems impossible for page based CHECKSUM_COMPLETE drivers to behave correctly in the case of rejected frames. Eg, there is no way to pass the partial checksum to the LRO module so that it gets set in the skb header and passed up the stack. Further, there seems to be no (easy) way to use CHECKSUM_COMPLETE on an aggregated packet at LRO flush time. By the time a packet is aggregated, the partial checksum from the first segment is out of date. I think it would make sense to require that a CHECKSUM_COMPLETE style driver verify the checksum in its get_frag_header / get_skb_header callback. This allows the LRO code to unconditionally set CHECKSUM_UNNECESSARY. The attached a patch modifies the code to do this. 2) Non-accelerated VLAN tags Our firmware currently does not do vlan tag insertion and removal. This causes a problem in __lro_proc_segment() where the tcp and ip headers are setup to point into the newly created skb. A frame containing an unstripped vlan tag will cause the headers to be garbage. The attached patch modifies __lro_proc_segment() to offset those pointers by VLAN_HLEN when required. 3) Padded frames. I may be missing something, but I don't see where you either strip padding from frames or reject padded frames. (see the pskb_trim_rcsum() in net/ipv4/ip_input.c:ip_rcv() I did not add such a feature as I was confused about the intended use of len/true_size. Also, trimming is a pain when dealing with pure frags (without a containing skb). We have code in our out-of-kernel driver to deal with it which you are welcome to use. 4) LRO_MIN_PG_HLEN (== 80) This confuses me. Can you please explain what you're trying to do? Because of this, I kept getting crashes in the skb_pull() done by eth_type_trans() because I was passing segments which were 60 bytes and the skb-data_len of the skb constructed by lro_gen_skb()
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
Hello. Scott Wood wrote: Also, what mmio-ide in the compat properly means in the context of ide_platform which is able to handle both port and memory mapped IDE. I/O-space is only valid in the context of PCI, ISA, or similar buses, and the bus-specific reg format indicates whether it's mmio-space or io-space. You could save time on lecturing me (and use it to look on the driver ;-). I think we must get rid with this crap, and since this IDE register mapping is pretty much board specific, call it something like mpc8349emitx-ide instead. What is board specific about a set of standard IDE registers at a given The regisrer mapping used is highly non-standard. address? Do we need to make board-specific glue code for all of the We're already in board specific code, so why the heck not? :-) various ns16550-compatibles out there as well? I never suggested that -- what I did suggest was make of_serial.c recognize certain chip types and register them with 8250 driver. -Scott MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver
Sergei Shtylyov wrote: It doesn't buy us anything in here, but it's conceivable that someone may want to write a driver that uses a shift in the I/O accessor rather than an array of port offsets, It wouldn't be IDE driver then, and neither it would be libata which also does this another way this (despite pata_platform uses shifts too -- not in the accessors, so no speed loss). The device tree is not just for Linux. equivalent of the cntlzw innstruction, and shift makes it clear that the stride must be power-of-two). Plus, using shift is consistent with what we do on ns16550. Why the heck should we care about the UART code taling about IDE?! Consistency? So, let me consider your argument purely speculative and invalid. ;-) Consider it whatever you want. :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: do section mismatch check on full vmlinux breaks powerpc build
Hi Sam- Sam Ravnborg wrote: On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote: 2.6.23-rc1 breaks the build for 64-bit powerpc for me (using maple_defconfig): LD vmlinux.o powerpc64-unknown-linux-gnu-ld: dynreloc miscount for kernel/built-in.o, section .opd powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 I narrowed it down to the following change to avoid the breakage: diff --git a/include/linux/mm.h b/include/linux/mm.h index c456c3a..2ea222f 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1246,7 +1246,7 @@ void drop_slab(void); extern int randomize_va_space; #endif -__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); +//__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); #endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ So seems that something goes a bit fishy when using weak symbols and this trigges a binutils bug. The above line was introdused in the following commit: commit f269fdd1829acc5e53bf57b145003e5733133f2b Author: David Howells [EMAIL PROTECTED] Date: Wed Sep 27 01:50:23 2006 -0700 [PATCH] NOMMU: move the fallback arch_vma_name() to a sensible place Thanks for looking into this. Removing the __attribute__((weak)) from arch_vma_name's declaration in linux/mm.h unbreaks the build for me. Maybe it shouldn't matter, but it seems unusual to have the weak attribute specified at the function's declaration. I wasn't able to find any examples of that for other weak functions in the kernel (e.g. sched_clock). ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: do section mismatch check on full vmlinux breaks powerpc build
On Wed, Jul 25, 2007 at 04:16:10PM -0500, Nathan Lynch wrote: Hi Sam- Sam Ravnborg wrote: On Tue, Jul 24, 2007 at 05:41:05PM -0500, Nathan Lynch wrote: 2.6.23-rc1 breaks the build for 64-bit powerpc for me (using maple_defconfig): LD vmlinux.o powerpc64-unknown-linux-gnu-ld: dynreloc miscount for kernel/built-in.o, section .opd powerpc64-unknown-linux-gnu-ld: can not edit opd Bad value make: *** [vmlinux.o] Error 1 I narrowed it down to the following change to avoid the breakage: diff --git a/include/linux/mm.h b/include/linux/mm.h index c456c3a..2ea222f 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -1246,7 +1246,7 @@ void drop_slab(void); extern int randomize_va_space; #endif -__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); +//__attribute__((weak)) const char *arch_vma_name(struct vm_area_struct *vma); #endif /* __KERNEL__ */ #endif /* _LINUX_MM_H */ So seems that something goes a bit fishy when using weak symbols and this trigges a binutils bug. The above line was introdused in the following commit: commit f269fdd1829acc5e53bf57b145003e5733133f2b Author: David Howells [EMAIL PROTECTED] Date: Wed Sep 27 01:50:23 2006 -0700 [PATCH] NOMMU: move the fallback arch_vma_name() to a sensible place Thanks for looking into this. Removing the __attribute__((weak)) from arch_vma_name's declaration in linux/mm.h unbreaks the build for me. Maybe it shouldn't matter, but it seems unusual to have the weak attribute specified at the function's declaration. I wasn't able to find any examples of that for other weak functions in the kernel (e.g. sched_clock). Unfortunately removing the weak attribute uncovered that x86_64 has two functions with the same name = link error. Needs to have that sorted first out but ball is rolling. (Se lkml for details) Sam ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
On Thu, 26 Jul 2007, Sergei Shtylyov wrote: Guennadi Liakhovetski wrote: Wrong list to submit sych stuff, post to linux-ide. Not entirely. The patch (or other patches in the series) would also touch ARM platforms in the mainline, currently using that driver. As I didn't Was worth cross-posting to linux-ide anyway to get the IDE experts' feedback. ;-) linux-arm* mailing lists do not allow cross-posting. have a chance to test them due to lack of hardware, I posted on arm, asking if anyone would test those platforms for me. ... and they laughed at you? ;-) No, noone had that hardware either:-) Those who had preferred to forget about it, I guess. It was largely in accordance with my own opinion, so, I chose to accept it:-) It's not clear why you decided to waste time on it then. :-) Because I myself was in the situation where my local version of the driver was filling with #ifdef's supporting all possible variations of our hardware, so, I switched it to platform_driver to clean up that mess. And then decided to ask if others would consider it useful. Just in case. I hoped they wouldn't. doubt, just wanted to double-check. So, why do we now need a new legacy (a/drivers/ide/legacy/ide_platform.c) driver when a modern driver exists? Good question (I know the answer but won't tell ;-). You've been very cooperative, thanks. In fact, I also highly doubt that we need it. What we'd need is an OF driver. Great, thanks. Now we have to find out why Alan acked it (added to cc). Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC 0/1] lro: Generic Large Receive Offload for TCP traffic
From: Andrew Gallatin [EMAIL PROTECTED] Date: Wed, 25 Jul 2007 13:17:54 -0400 I've ported myri10ge to use the new LRO interface. I have attached a preliminary patch to myri10ge. I'm very pleased to note that the performance is on-par with my own LRO used by our out-of-tree driver. (except when using mixed MTUS, see performance data below). Thanks for posting this port and feedback on the generic LRO code. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Fix ibmvscsi client for multiplatform iSeries+pSeries kernel.
On Wed, 2007-07-25 at 15:41 +0100, David Woodhouse wrote:
If you build a multiplatform kernel for iSeries and pSeries, with
ibmvscsic support, the resulting client doesn't work on iSeries.
This patch should fix that, using the appropriate low-level operations
for the machine detected at runtime.
Signed-off-by: David Woodhouse [EMAIL PROTECTED]
Nice that someone finally fixed this up.
But I get:
drivers/scsi/ibmvscsi/ibmvscsi.c:1651: error: 'FW_FEATURE_ISERIES' undeclared
(first use in this function)
drivers/scsi/ibmvscsi/ibmvscsi.c:1651: error: (Each undeclared identifier is
reported only once
drivers/scsi/ibmvscsi/ibmvscsi.c:1651: error: for each function it appears in.)
drivers/scsi/ibmvscsi/ibmvscsi.c:1653: error: 'FW_FEATURE_VIO' undeclared
(first use in this function)
Missing asm/firmware.h ?
cheers
--- linux-2.6.19.ppc64/drivers/scsi/ibmvscsi/rpa_vscsi.c~ 2006-11-29
21:57:37.0 +
+++ linux-2.6.19.ppc64/drivers/scsi/ibmvscsi/rpa_vscsi.c 2006-12-19
15:42:57.0 +
@@ -42,14 +42,14 @@ static unsigned int partition_number = -
* Routines for managing the command/response queue
*/
/**
- * ibmvscsi_handle_event: - Interrupt handler for crq events
+ * rpavscsi_handle_event: - Interrupt handler for crq events
* @irq: number of irq to handle, not used
* @dev_instance: ibmvscsi_host_data of host that received interrupt
*
* Disables interrupts and schedules srp_task
* Always returns IRQ_HANDLED
*/
-static irqreturn_t ibmvscsi_handle_event(int irq, void *dev_instance)
+static irqreturn_t rpavscsi_handle_event(int irq, void *dev_instance)
{
struct ibmvscsi_host_data *hostdata =
(struct ibmvscsi_host_data *)dev_instance;
@@ -66,9 +66,9 @@ static irqreturn_t ibmvscsi_handle_event
* Frees irq, deallocates a page for messages, unmaps dma, and unregisters
* the crq with the hypervisor.
*/
-void ibmvscsi_release_crq_queue(struct crq_queue *queue,
- struct ibmvscsi_host_data *hostdata,
- int max_requests)
+static void rpavscsi_release_crq_queue(struct crq_queue *queue,
+struct ibmvscsi_host_data *hostdata,
+int max_requests)
{
long rc;
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -108,12 +108,13 @@ static struct viosrp_crq *crq_queue_next
}
/**
- * ibmvscsi_send_crq: - Send a CRQ
+ * rpavscsi_send_crq: - Send a CRQ
* @hostdata:the adapter
* @word1: the first 64 bits of the data
* @word2: the second 64 bits of the data
*/
-int ibmvscsi_send_crq(struct ibmvscsi_host_data *hostdata, u64 word1, u64
word2)
+static int rpavscsi_send_crq(struct ibmvscsi_host_data *hostdata,
+ u64 word1, u64 word2)
{
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -121,10 +122,10 @@ int ibmvscsi_send_crq(struct ibmvscsi_ho
}
/**
- * ibmvscsi_task: - Process srps asynchronously
+ * rpavscsi_task: - Process srps asynchronously
* @data:ibmvscsi_host_data of host
*/
-static void ibmvscsi_task(void *data)
+static void rpavscsi_task(void *data)
{
struct ibmvscsi_host_data *hostdata = (struct ibmvscsi_host_data *)data;
struct vio_dev *vdev = to_vio_dev(hostdata-dev);
@@ -189,6 +190,42 @@ static void set_adapter_info(struct ibmv
}
/**
+ * reset_crq_queue: - resets a crq after a failure
+ * @queue: crq_queue to initialize and register
+ * @hostdata:ibmvscsi_host_data of host
+ *
+ */
+static int rpavscsi_reset_crq_queue(struct crq_queue *queue,
+ struct ibmvscsi_host_data *hostdata)
+{
+ int rc;
+ struct vio_dev *vdev = to_vio_dev(hostdata-dev);
+
+ /* Close the CRQ */
+ do {
+ rc = plpar_hcall_norets(H_FREE_CRQ, vdev-unit_address);
+ } while ((rc == H_BUSY) || (H_IS_LONG_BUSY(rc)));
+
+ /* Clean out the queue */
+ memset(queue-msgs, 0x00, PAGE_SIZE);
+ queue-cur = 0;
+
+ set_adapter_info(hostdata);
+
+ /* And re-open it again */
+ rc = plpar_hcall_norets(H_REG_CRQ,
+ vdev-unit_address,
+ queue-msg_token, PAGE_SIZE);
+ if (rc == 2) {
+ /* Adapter is good, but other end is not ready */
+ printk(KERN_WARNING ibmvscsi: Partner adapter not ready\n);
+ } else if (rc != 0) {
+ printk(KERN_WARNING
+ibmvscsi: couldn't register crq--rc 0x%x\n, rc);
+ }
+ return rc;
+}
+/**
* initialize_crq_queue: - Initializes and registers CRQ with hypervisor
* @queue: crq_queue to initialize and register
* @hostdata:ibmvscsi_host_data of host
@@ -197,9 +234,9 @@ static void set_adapter_info(struct ibmv
* the crq with the hypervisor.
* Returns zero on success.
*/
-int
[PATCH 1/2] powerpc: Marvell 64x60 EDAC platform devices setup
Creating platform devices (memory controller, sram error registers, cpu
error registers, PCI error registers) for Error Detection and Correction
(EDAC) driver.
The platform devices allow the mv64x60 EDAC driver to detect errors from
the memory controller (ECC erorrs), SRAM controller, CPU data path error
registers, and PCI error registers. The errors are reported to syslog.
Software ECC scrubbing is provided. These replace the mv64x60 error handlers
in the ppc branch. They are being moved to EDAC subsystem in order to
centralize error reporting.
The error reporting can be triggered via interrupts from the mv64x60 bridge
chip or via polling mechanism provided by the EDAC core code.
Signed-off-by: Dave Jiang [EMAIL PROTECTED]
Acked-by: Dale Farnsworth [EMAIL PROTECTED]
---
arch/powerpc/sysdev/mv64x60_dev.c | 115 +
1 files changed, 103 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/sysdev/mv64x60_dev.c
b/arch/powerpc/sysdev/mv64x60_dev.c
index b618fa6..bc8cd5a 100644
--- a/arch/powerpc/sysdev/mv64x60_dev.c
+++ b/arch/powerpc/sysdev/mv64x60_dev.c
@@ -17,6 +17,7 @@
#include linux/platform_device.h
#include asm/prom.h
+#include asm/io.h
/*
* These functions provide the necessary setup for the mv64x60 drivers.
@@ -390,30 +391,120 @@ error:
return err;
}
+static int __init mv64x60_edac_pdev_init(struct device_node *np,
+ int id,
+ int num_addr,
+ char *pdev_name)
+{
+ struct resource *r;
+ struct platform_device *pdev;
+ int i, ret;
+
+ r = kzalloc(num_addr * sizeof(*r) + sizeof(*r), GFP_KERNEL);
+ if (!r)
+ return -ENOMEM;
+
+ for (i = 0; i num_addr; i++) {
+ ret = of_address_to_resource(np, i, r[i]);
+ if (ret) {
+ kfree(r);
+ return ret;
+ }
+ }
+
+ of_irq_to_resource(np, 0, r[i]);
+
+ pdev = platform_device_register_simple(pdev_name, id, r, num_addr + 1);
+
+ kfree(r);
+
+ if (IS_ERR(pdev))
+ return PTR_ERR(pdev);
+
+ return 0;
+}
+
+#ifdef CONFIG_PCI
+/*
+ * Bit 0 of MV64x60_PCIx_ERR_MASK does not exist on the 64360 and because of
+ * errata FEr-#11 and FEr-##16 for the 64460, it should be 0 on that chip as
+ * well. IOW, don't set bit 0.
+ */
+#define MV64X60_PCIx_ERR_MASK_VAL 0x00a50c24
+
+/* Erratum FEr PCI-#16: clear bit 0 of PCI SERRn Mask reg. */
+static int __init mv64x60_pci_fixup(struct device_node *np)
+{
+ struct resource res;
+ void __iomem *pci_serr;
+ int ret;
+
+ ret = of_address_to_resource(np, 1, res);
+ if (ret)
+ return ret;
+
+ pci_serr = ioremap(res.start, res.end - res.start + 1);
+ if (!pci_serr)
+ return -ENOMEM;
+
+ out_le32(pci_serr, in_le32(pci_serr) ~0x1);
+ iounmap(pci_serr);
+
+ return 0;
+}
+#endif /* CONFIG_PCI */
+
static int __init mv64x60_device_setup(void)
{
struct device_node *np = NULL;
int id;
int err;
- for (id = 0;
-(np = of_find_compatible_node(np, serial, marvell,mpsc)); id++)
- if ((err = mv64x60_mpsc_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, serial, marvell,mpsc)
+ if ((err = mv64x60_mpsc_device_setup(np, id++)))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, network, marvell,mv64x60-eth)
+ if ((err = mv64x60_eth_device_setup(np, id++)))
goto error;
- for (id = 0;
-(np = of_find_compatible_node(np, network,
- marvell,mv64x60-eth));
-id++)
- if ((err = mv64x60_eth_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, i2c, marvell,mv64x60-i2c)
+ if ((err = mv64x60_i2c_device_setup(np, id++)))
goto error;
- for (id = 0;
-(np = of_find_compatible_node(np, i2c, marvell,mv64x60-i2c));
-id++)
- if ((err = mv64x60_i2c_device_setup(np, id)))
+ id = 0;
+ for_each_compatible_node(np, NULL, marvell,mv64x60-mem-ctrl)
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+ mv64x60_mc_err)))
goto error;
+ id = 0;
+ for_each_compatible_node(np, NULL, marvell,mv64x60-cpu-error)
+ if ((err = mv64x60_edac_pdev_init(np, id++, 2,
+ mv64x60_cpu_err)))
+ goto error;
+
+ id = 0;
+ for_each_compatible_node(np, NULL, marvell,mv64x60-sram-ctrl)
+ if ((err = mv64x60_edac_pdev_init(np, id++, 1,
+
Re: [PATCH] Re: 2.6.22-git hangs during boot on PowerBook G3 in 0.0 seconds
Kim Phillips writes: In which circumstances are you trying to translate an address with no size cell ? for the enumerated PHYs. As the original commit comment states, I was getting these messages: prom_parse: Bad cell count for /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] prom_parse: Bad cell count for /[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED] Specifically, which of_address_to_resource or other call is producing these error messages? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] fix ppc kernels after build-id addition
Meelis Roos writes: This patch fixes arch/ppc kernels, at least for prep subarch, after build-id addition. Without the patch, kernels were 3 times the size and bootloader refused to load them. Now they are back to normal again. I just built an ARCH=ppc kernel for the prep subarch and the vmlinux size was normal. Can you identify exactly why the kernels got so much bigger, i.e. what is taking up all the space? Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc: Add function to check if address is an IO port
This adds a function that tells you if a given kernel virtual address
is hitting a PCI or ISA IO port permanent mapping or not. This is to
be used in the next patch to fix iomap APIs to properly unmap things.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/pci-common.c | 23 +++
include/asm-powerpc/pci-bridge.h | 20
2 files changed, 43 insertions(+)
Index: linux-work/arch/powerpc/kernel/pci-common.c
===
--- linux-work.orig/arch/powerpc/kernel/pci-common.c2007-07-26
13:21:41.0 +1000
+++ linux-work/arch/powerpc/kernel/pci-common.c 2007-07-26 13:38:48.0
+1000
@@ -101,6 +101,29 @@ void pcibios_free_controller(struct pci_
kfree(phb);
}
+int pcibios_vaddr_is_ioport(void __iomem *address)
+{
+ int ret = 0;
+ struct pci_controller *hose;
+ unsigned long size;
+
+ spin_lock(hose_spinlock);
+ list_for_each_entry(hose, hose_list, list_node) {
+#ifdef CONFIG_PPC64
+ size = hose-pci_io_size;
+#else
+ size = hose-io_resource.end - hose-io_resource.start + 1;
+#endif
+ if (address = hose-io_base_virt
+ address (hose-io_base_virt + size)) {
+ ret = 1;
+ break;
+ }
+ }
+ spin_unlock(hose_spinlock);
+ return ret;
+}
+
/*
* Return the domain number for this bus.
*/
Index: linux-work/include/asm-powerpc/pci-bridge.h
===
--- linux-work.orig/include/asm-powerpc/pci-bridge.h2007-07-26
13:21:41.0 +1000
+++ linux-work/include/asm-powerpc/pci-bridge.h 2007-07-26 14:01:01.0
+1000
@@ -64,6 +64,14 @@ static inline struct pci_controller *pci
return bus-sysdata;
}
+static inline int isa_vaddr_is_ioport(void __iomem *address)
+{
+ /* No specific ISA handling on ppc32 at this stage, it
+* all goes through PCI
+*/
+ return 0;
+}
+
/* These are used for config access before all the PCI probing
has been done. */
int early_read_config_byte(struct pci_controller *hose, int bus, int dev_fn,
@@ -231,6 +239,13 @@ extern void pcibios_free_controller(stru
extern void isa_bridge_find_early(struct pci_controller *hose);
+static inline int isa_vaddr_is_ioport(void __iomem *address)
+{
+ /* Check if address hits the reserved legacy IO range */
+ unsigned long ea = (unsigned long)address;
+ return ea = ISA_IO_BASE ea ISA_IO_END;
+}
+
extern int pcibios_unmap_io_space(struct pci_bus *bus);
extern int pcibios_map_io_space(struct pci_bus *bus);
@@ -261,11 +276,16 @@ extern struct pci_controller *
pcibios_alloc_controller(struct device_node *dev);
#ifdef CONFIG_PCI
extern unsigned long pci_address_to_pio(phys_addr_t address);
+extern int pcibios_vaddr_is_ioport(void __iomem *address);
#else
static inline unsigned long pci_address_to_pio(phys_addr_t address)
{
return (unsigned long)-1;
}
+static inline int pcibios_vaddr_is_ioport(void __iomem *address)
+{
+ return 0;
+}
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc: Make pci_iounmap actually unmap things
This patch uses the newly added functions for testing if an address is
an ISA or PCI IO port to properly unmap things in pci_iounmap that
aren't such ports. Without that, drivers using the iomap API will never
actually unmap resources which on IBM server machines will prevent
hot-unplug of the corresponding HW adapters.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
arch/powerpc/kernel/iomap.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
Index: linux-work/arch/powerpc/kernel/iomap.c
===
--- linux-work.orig/arch/powerpc/kernel/iomap.c 2007-07-26 13:44:23.0
+1000
+++ linux-work/arch/powerpc/kernel/iomap.c 2007-07-26 13:50:48.0
+1000
@@ -7,6 +7,7 @@
#include linux/pci.h
#include linux/mm.h
#include asm/io.h
+#include asm/pci-bridge.h
/*
* Here comes the ppc64 implementation of the IOMAP
@@ -136,7 +137,12 @@ void __iomem *pci_iomap(struct pci_dev *
void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
{
- /* Nothing to do */
+ if (isa_vaddr_is_ioport(addr))
+ return;
+ if (pcibios_vaddr_is_ioport(addr))
+ return;
+ iounmap(addr);
}
+
EXPORT_SYMBOL(pci_iomap);
EXPORT_SYMBOL(pci_iounmap);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] gfar: Fix modpost warning
Fix the following modpost warning:
WARNING: vmlinux.o(.init.text+0x1aa6c): Section mismatch: reference to
.exit.text:gfar_mdio_exit (between 'gfar_init' and 'gfar_mdio_init')
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
drivers/net/gianfar_mii.c |2 +-
drivers/net/gianfar_mii.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/gianfar_mii.c b/drivers/net/gianfar_mii.c
index ac3596f..100bf41 100644
--- a/drivers/net/gianfar_mii.c
+++ b/drivers/net/gianfar_mii.c
@@ -245,7 +245,7 @@ int __init gfar_mdio_init(void)
return driver_register(gianfar_mdio_driver);
}
-void __exit gfar_mdio_exit(void)
+void gfar_mdio_exit(void)
{
driver_unregister(gianfar_mdio_driver);
}
diff --git a/drivers/net/gianfar_mii.h b/drivers/net/gianfar_mii.h
index 5d34004..b373091 100644
--- a/drivers/net/gianfar_mii.h
+++ b/drivers/net/gianfar_mii.h
@@ -42,5 +42,5 @@ struct gfar_mii {
int gfar_mdio_read(struct mii_bus *bus, int mii_id, int regnum);
int gfar_mdio_write(struct mii_bus *bus, int mii_id, int regnum, u16 value);
int __init gfar_mdio_init(void);
-void __exit gfar_mdio_exit(void);
+void gfar_mdio_exit(void);
#endif /* GIANFAR_PHY_H */
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH v2][POWERPC] Don't try to allocate resources for a POWERPC PHB
From e314b31e4650c789829bf870f83ee7ae4be46426 Mon Sep 17 00:00:00 2001
From: Kumar Gala [EMAIL PROTECTED]
Date: Wed, 25 Jul 2007 00:44:11 -0500
Subject: [PATCH] [POWERPC] Don't try to allocate resources for a POWERPC PHB
The Freescale PCI PHBs actual report back values in the BAR registers
this causes issues in that we try to allocate resources for them
and will get error messages like the following on MPC8544 DS:
PCI: Failed to allocate mem resource #1:[EMAIL PROTECTED] for :00:00.0
To address this if we are class PCI_CLASS_PROCESSOR_POWERPC, a normal
header type, and the PHB we clear out all the resources.
Signed-off-by: Kumar Gala [EMAIL PROTECTED]
---
Ben suggested to do this by a quirk and blow away the resources which I
like better.
- k
arch/powerpc/kernel/pci_32.c | 18 ++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 721a694..ec80779 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -60,6 +60,24 @@ LIST_HEAD(hose_list);
static int pci_bus_count;
static void
+fixup_broken_fsl(struct pci_dev* dev)
+{
+ int i, class = dev-class 8;
+
+ if ((class == PCI_CLASS_PROCESSOR_POWERPC)
+ (dev-hdr_type == PCI_HEADER_TYPE_NORMAL)
+ (dev-bus-parent == NULL)) {
+ for (i = 0; i DEVICE_COUNT_RESOURCE; i++) {
+ dev-resource[i].start = 0;
+ dev-resource[i].end = 0;
+ dev-resource[i].flags = 0;
+ }
+ }
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MOTOROLA, PCI_ANY_ID, fixup_broken_fsl);
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_FREESCALE, PCI_ANY_ID,
fixup_broken_fsl);
+
+static void
fixup_broken_pcnet32(struct pci_dev* dev)
{
if ((dev-class8 == PCI_CLASS_NETWORK_ETHERNET)) {
--
1.5.2.2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: pte_offset_map for ppc assumes HIGHPTE
On Wed, 2007-07-25 at 17:16 -0500, Satya wrote: hello, The implementation of pte_offset_map() for ppc assumes that PTEs are kept in highmem (CONFIG_HIGHPTE). There is only one implmentation of pte_offset_map() as follows (include/asm-ppc/pgtable.h): #define pte_offset_map(dir, addr) \ ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE0) + pte_index(addr)) Shouldn't this be made conditional according to CONFIG_HIGHPTE is defined or not (as implemented in include/asm-i386/pgtable.h) ? the same goes for pte_offset_map_nested and the corresponding unmap functions. Do we have CONFIG_HIGHMEM without CONFIG_HIGHPTE ? If yes, then indeed, we should change that. Though I'm not sure I see the point of splitting those 2 options. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
On Wed, 25 Jul 2007, Sergei Shtylyov wrote: Guennadi Liakhovetski wrote: This is now very similar to pata_platform.c, they both use same platform data structure and same resources. To achieve that, byte_lanes_swapping platform data variable and platform specified iops removed from that driver. It's fine, since those were never used anyway. pata_platform and ide_platform are carrying same driver names, to easily switch between these drivers, without need to touch platform code. Why? There's a drivers/ide/arm/ide_arm.c IDe driver that some platforms (not in the mainline) hack to access, e.g., CF cards in true-IDE mode. About a month ago I submitted a patch to arm-linux-kernel switching that Wrong list to submit sych stuff, post to linux-ide. Not entirely. The patch (or other patches in the series) would also touch ARM platforms in the mainline, currently using that driver. As I didn't have a chance to test them due to lack of hardware, I posted on arm, asking if anyone would test those platforms for me. driver to using platform-device. I got a reply, that it's not worth it now that IDE is slowly becoming obsolete, and the pata_platform serves the perpose perfectly well. I found this argument reasonable, I had the same Ignore such replies in the future. ;-) It was largely in accordance with my own opinion, so, I chose to accept it:-) doubt, just wanted to double-check. So, why do we now need a new legacy (a/drivers/ide/legacy/ide_platform.c) driver when a modern driver exists? Good question (I know the answer but won't tell ;-). You've been very cooperative, thanks. Thanks Guennadi --- Guennadi Liakhovetski ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver
Scott Wood wrote: It doesn't buy us anything in here, but it's conceivable that someone may want to write a driver that uses a shift in the I/O accessor rather than an array of port offsets, It wouldn't be IDE driver then, and neither it would be libata which also does this another way this (despite pata_platform uses shifts too -- not in the accessors, so no speed loss). The device tree is not just for Linux. Yeah, and I can't wait to see some other its users. ;-) This doesn't mean that shift is better anyway. If everyone considers it better, I give up. But be warned that shift (stride) is not the only property characterizing register accesses -- the regs might be only accessible as 16/32-bit quantities, for example (16-bit is a real world example -- from Amiga or smth of that sort, IIRC). equivalent of the cntlzw innstruction, and shift makes it clear that the stride must be power-of-two). Plus, using shift is consistent with what we do on ns16550. Why the heck should we care about the UART code taling about IDE?! Consistency? We're not obliged to be consistent with every piece of the kernel code. -Scott MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
Hello. Scott Wood wrote: +hwif-hw.io_ports[IDE_DATA_OFFSET] = port; + +port += (1 pdata-ioport_shift); +for (i = IDE_ERROR_OFFSET; i = IDE_STATUS_OFFSET; + i++, port += (1 pdata-ioport_shift)) Looks like shift doesn't buy as anything, why not just use stride? It doesn't buy us anything in here, but it's conceivable that someone may want to write a driver that uses a shift in the I/O accessor rather than an array of port offsets, It wouldn't be IDE driver then, and neither it would be libata which also does this another way this (despite pata_platform uses shifts too -- not in the accessors, so no speed loss). and it's easier to convert a shift to a stride than the other way around (not all architectures have an equivalent of the cntlzw innstruction, and shift makes it clear that the stride must be power-of-two). Plus, using shift is consistent with what we do on ns16550. Why the heck should we care about the UART code taling about IDE?! So, let me consider your argument purely speculative and invalid. ;-) -Scott WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] [IDE] Platform IDE driver (was: MMIO IDE driver)
Vitaly Bordug wrote:
This is now very similar to pata_platform.c, they both use
same platform data structure and same resources.
To achieve that, byte_lanes_swapping platform data variable
and platform specified iops removed from that driver. It's fine,
since those were never used anyway.
Hopefully, PPC will never need them.
pata_platform and ide_platform are carrying same driver names,
to easily switch between these drivers, without need to touch
platform code.
diff --git a/drivers/ide/legacy/ide_platform.c
b/drivers/ide/legacy/ide_platform.c
new file mode 100644
index 000..0b3f5b5
--- /dev/null
+++ b/drivers/ide/legacy/ide_platform.c
@@ -0,0 +1,181 @@
+/*
+ * Platform IDE driver
+ *
+ * Copyright (C) 2007 MontaVista Software
+ *
+ * Maintainer: Kumar Gala [EMAIL PROTECTED]
Poor Kumar, I guess he was surprised be being assigned a maintainer of the
driver he didn't write (well, even if it borrowed some code from his earlier
one ;-)...
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ */
+
+#include linux/types.h
+#include linux/init.h
+#include linux/kernel.h
+#include linux/ide.h
+#include linux/ioport.h
+#include linux/module.h
+#include linux/pata_platform.h
+#include linux/io.h
+
+static struct {
+ void __iomem *plat_ide_mapbase;
+ void __iomem *plat_ide_alt_mapbase;
+ ide_hwif_t *hwif;
+ int index;
+} hwif_prop;
+
+static ide_hwif_t *__devinit plat_ide_locate_hwif(void __iomem *base,
+ void __iomem *ctrl, struct pata_platform_info *pdata, int irq,
+ int mmio)
+{
+ unsigned long port = (unsigned long)base;
+ ide_hwif_t *hwif;
+ int index, i;
+
+ for (index = 0; index MAX_HWIFS; ++index) {
+ hwif = ide_hwifs + index;
+ if (hwif-io_ports[IDE_DATA_OFFSET] == port)
+ goto found;
+ }
+
+ for (index = 0; index MAX_HWIFS; ++index) {
+ hwif = ide_hwifs + index;
+ if (hwif-io_ports[IDE_DATA_OFFSET] == 0)
+ goto found;
+ }
+
+ return NULL;
+
+found:
+
+ hwif-hw.io_ports[IDE_DATA_OFFSET] = port;
+
+ port += (1 pdata-ioport_shift);
+ for (i = IDE_ERROR_OFFSET; i = IDE_STATUS_OFFSET;
+ i++, port += (1 pdata-ioport_shift))
Looks like shift doesn't buy as anything, why not just use stride?
+ hwif-hw.io_ports[i] = port;
+
+ hwif-hw.io_ports[IDE_CONTROL_OFFSET] = (unsigned long)ctrl;
+
+ memcpy(hwif-io_ports, hwif-hw.io_ports, sizeof(hwif-hw.io_ports));
+ hwif-hw.irq = hwif-irq = irq;
+
+ hwif-hw.dma = NO_DMA;
+ hwif-hw.chipset = ide_generic;
+
+ if (mmio) {
+ hwif-mmio = 1;
+ default_hwif_mmiops(hwif);
+ }
And why default_hwif_iops(hwif) is not called else?
And I remember the previos variant was overriding INSW()/OUTSW() methods
-- turned out to be unnecessary? :-)
+
+ hwif_prop.hwif = hwif;
+ hwif_prop.index = index;
+
+ return hwif;
+}
+
+static int __devinit plat_ide_probe(struct platform_device *pdev)
+{
+ struct resource *res_base, *res_alt, *res_irq;
+ ide_hwif_t *hwif;
+ struct pata_platform_info *pdata;
+ int ret = 0;
+ int mmio = 0;
+
+ pdata = pdev-dev.platform_data;
+
+ /* get a pointer to the register memory */
+ res_base = platform_get_resource(pdev, IORESOURCE_IO, 0);
+ res_alt = platform_get_resource(pdev, IORESOURCE_IO, 1);
+
+ if (!res_base || !res_alt) {
+ res_base = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res_alt = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res_base || !res_alt) {
+ ret = -ENOMEM;
ENODEV or EINVAL you mean? :-)
+ goto out;
Bleh... just return please.
+ }
+ mmio = 1;
+ }
+
+ res_irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!res_irq) {
+ ret = -EINVAL;
+ goto out;
Bleh... return -EINVAL, please. Or maybe -ENODEV.
+ }
+
[...]
+ hwif = plat_ide_locate_hwif(hwif_prop.plat_ide_mapbase,
+ hwif_prop.plat_ide_alt_mapbase, pdata, res_irq-start, mmio);
+
+ if (!hwif) {
+ ret = -ENODEV;
+ goto out;
Bleh... please just
return -ENODEV.
+ }
+ hwif-gendev.parent = pdev-dev;
+ hwif-noprobe = 0;
+
+ probe_hwif_init(hwif);
+
+ platform_set_drvdata(pdev, hwif);
+ ide_proc_register_port(hwif);
+
+ return 0;
+
+out:
No need to abuse the function cleanup style when you have nothing to
cleanup. :-/
+ return ret;
+}
+
+static int __devexit
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
Sergei Shtylyov wrote: I acn undertand your complaint in the context of an OF driver (which we don't have yet) but mmio-ide just means nothing to the current driver, and it doesn't convery enough info on the programming interface for the conceivable OF driver, it also does need to know at least reg-stride (and maybe reg-size in case only 16/32-bit accesses can be used). Well, if such driver will be written, I/O mapping support will probably be dropped from it, so indeed, calling it mmio-ide.c would make sense. But that can be added when this driver is done, and for now I don't think the details of what Linux code currently exists should drive the device tree binding. That the current patches use platform_device glue code is an implementation detail (and one I'd rather see go away, in favor of a driver that supports both platform_device and of_device). I'd really prefer the board name to appear in the compatible prop (to which mmio-ide can be appended)... Sure, that's always good... it was the instead that I objected to. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Re: 2.6.22-git hangs during boot on PowerBook G3 in 0.0 seconds
Kim Phillips writes: but yeah, size-cells should be allowed to be 0 (even address-cells) and it may be the case that the Lombard needs some fixup code. So it turns out that the nvram is under the via-pmu node on the Lombard. The via-pmu node has #size-cells == 0, which is correct since things under the via-pmu aren't directly accessible. The nvram driver code relies on not being able to translate an address for the nvram nodes on machines where the nvram isn't directly accessible. That is, it looks for nvram nodes, and if it can translate the address, assumes it can access the nvram directly. So nothing is incorrect here except your patch. :) I'll revert it. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: DTC 1.0.0 Release Coming?
On Wed, Jul 25, 2007 at 11:12:00AM -0500, Jon Loeliger wrote: Folks, I'd like to make an official DTC Version 1.0.0 release soon! To that end, I've published a repo on jdl.com with a v1.0.0-rc1 tag on it. I anticipate some updates to the Documentation before a final 1.0.0 release still. However, if you have something you would like to have be in The Real 1.0.0 release, please let me know soon! It would certainly be great to have a release, since dtc is becoming necessary for more and more kernel builds. Only thing I'm not really happy with in the current release is the versioning stuff. For starters, it always reports my builds as -dirty, even when they're not. It also seems a bit hideously complicated for what it does. I'd prefer to see something simpler using git-describe to derive the version strings directly from the git tags themselves. Obviously we need some sort of cacheing mechanism to make the versioning work for tarball releases without the git history, but I think we can handle that with a suitable make dist target. I'll see if I can make a patch or two in the next few days. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
On Wed, Jul 25, 2007 at 09:54:07PM +0400, Sergei Shtylyov wrote: Also, what mmio-ide in the compat properly means in the context of ide_platform which is able to handle both port and memory mapped IDE. I/O-space is only valid in the context of PCI, ISA, or similar buses, and the bus-specific reg format indicates whether it's mmio-space or io-space. I think we must get rid with this crap, and since this IDE register mapping is pretty much board specific, call it something like mpc8349emitx-ide instead. What is board specific about a set of standard IDE registers at a given address? Do we need to make board-specific glue code for all of the various ns16550-compatibles out there as well? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/2] [POWERPC] MPC8349E-mITX: use platform IDE driver for CF interface
Sergei Shtylyov wrote: Hello. Scott Wood wrote: Also, what mmio-ide in the compat properly means in the context of ide_platform which is able to handle both port and memory mapped IDE. I/O-space is only valid in the context of PCI, ISA, or similar buses, and the bus-specific reg format indicates whether it's mmio-space or io-space. You could save time on lecturing me (and use it to look on the driver ;-). Sorry, I misread the question as being a mismatch between the capabilities of the device binding and the driver, not about the specific compatible name. Something like generic-ide would probably be better. What is board specific about a set of standard IDE registers at a given The regisrer mapping used is highly non-standard. The gap between registers is nonstandard, but that's a fairly common type of noncompliance in embedded-land, and probably merits being supported in a generic way. I wouldn't call it highly nonstandard. Is there some other non-standardness that I'm missing? We're already in board specific code, so why the heck not? :-) various ns16550-compatibles out there as well? I never suggested that -- what I did suggest was make of_serial.c recognize certain chip types and register them with 8250 driver. What would be the advantage of maintaining a list of chips whose only difference is register spacing, rather than just using reg-shift and being done with it? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
pte_offset_map for ppc assumes HIGHPTE
hello, The implementation of pte_offset_map() for ppc assumes that PTEs are kept in highmem (CONFIG_HIGHPTE). There is only one implmentation of pte_offset_map() as follows (include/asm-ppc/pgtable.h): #define pte_offset_map(dir, addr) \ ((pte_t *) kmap_atomic(pmd_page(*(dir)), KM_PTE0) + pte_index(addr)) Shouldn't this be made conditional according to CONFIG_HIGHPTE is defined or not (as implemented in include/asm-i386/pgtable.h) ? the same goes for pte_offset_map_nested and the corresponding unmap functions. thanks, Satya Popuri ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
