Re: build failure on powerpc with current -git
On Fri, Oct 17, 2008 at 01:32:59PM -0600, Chris Friesen wrote: > The current -git fails to build on 64-bit powerpc (failure log below) . > Initially I tried using my older toolchain, when I first saw the problem > I built a new toolchain with crosstool (gcc 4.1.2 and binutils 2.16.1) > and tried again but got the same problem. > > 2.6.27 doesn't show this problem. > > Any ideas what's going on and how I can fix it? This is a know bug with binutils 2.16.1. You can work around it by either reverting commit 549e8152de8039506f69c677a4546e5427aa6ae7 or upgrading to a newer version of binutils. Nobody has a fix for this problem yet. (it's definitely a binutils bug, but the kernel exposed it where it wasn't an issue before. I don't know if support for 2.16.1 is going to be depreciated due to this. It seems like there are still a fair few users of binutils 2.16.1) g. > > Thanks, > > Chris > > > LD vmlinux.o > MODPOST vmlinux.o > WARNING: modpost: Found 4 section mismatch(es). > To see full details build your kernel with: > 'make CONFIG_DEBUG_SECTION_MISMATCH=y' > GEN .version > CHK include/linux/compile.h > UPD include/linux/compile.h > CC init/version.o > LD init/built-in.o > LD .tmp_vmlinux1 > /opt/crosstool/gcc-4.1.2-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld: > > BFD 2.16.1 internal error, aborting at > /home/cfriesen/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.6/binutils-2.16.1/bfd/elflink.c > > line 6419 in elf_link_output_extsym > > /opt/crosstool/gcc-4.1.2-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld: > > Please report this bug. > > make[1]: *** [.tmp_vmlinux1] Error 1 > make: *** [sub-make] Error 2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Please pull linux-2.6-mpc52xx
The following changes since commit 6dc6472581f693b5fc95aebedf67b4960fb85cf0: Benjamin Herrenschmidt (1): Merge commit 'origin' are available in the git repository at: git://git.secretlab.ca/git/linux-2.6-mpc52xx merge Grant Likely (1): powerpc/52xx: Make cuImage more robust in locating immr node. Wolfram Sang (2): powerpc/mpc5200: Don't touch pipelining for MPC5200B powerpc/mpc5200: Refactor FEC mdio read/write routines arch/powerpc/boot/cuboot-52xx.c |4 ++ arch/powerpc/platforms/52xx/mpc52xx_common.c |7 ++- drivers/net/fec_mpc52xx_phy.c| 55 ++--- 3 files changed, 31 insertions(+), 35 deletions(-) -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: Add cuImage.initrd.% target
From: Grant Likely <[EMAIL PROTECTED]> This target is needed to build cuImages with an embedded ramdisk image. Signed-off-by: Grant Likely <[EMAIL PROTECTED]> --- arch/powerpc/boot/Makefile |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile index aac1406..d83c642 100644 --- a/arch/powerpc/boot/Makefile +++ b/arch/powerpc/boot/Makefile @@ -319,6 +319,9 @@ $(obj)/zImage.iseries: vmlinux $(obj)/uImage: vmlinux $(wrapperbits) $(call if_changed,wrap,uboot) +$(obj)/cuImage.initrd.%: vmlinux $(obj)/%.dtb $(wrapperbits) + $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb,$(obj)/ramdisk.image.gz) + $(obj)/cuImage.%: vmlinux $(obj)/%.dtb $(wrapperbits) $(call if_changed,wrap,cuboot-$*,,$(obj)/$*.dtb) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: device tree variations
David Gibson wrote:
> Deleting the irrelevant parts or picking a device tree to pass to
> fdt_init() are both reasonable solutions. libfdt which is included in
> the bootwrapper has functions for removing unwanted nodes: either
> fdt_nop_node() or fdt_del_node() will suffice. There isn't currently
> a dt_ops hook to call though to those functions though. You could
> either add one, or (knowing that your platform always has a flat dt)
> bypass the dt_ops hooks and call libfdt directly.
Thanks. The fdt_del_node approach works pretty nicely. I added a
dt_ops hook since fdt is static in libfdt-wrapper.c.
At first I tried fdt_nop_node, fearing that find_node_by_prop_value()
and fdt_del_node() would interact badly when deleting in mid-traversal,
but it turns out that fdt_nop_node() upsets find_node_by_prop_value()
anyway. Plus, the kernel prints harmless but strange messages when
there are NOPs in the tree. So I use fdt_del_node() and rescan from
the top each time I delete a node and it works fine.
/* Find all product-dependent nodes and delete inapplicable ones. */
dev = NULL;
while ((dev = find_node_by_prop_value(dev,
"product-dependent",
"", 0)) != NULL) {
u32 mask;
int len;
len = getprop(dev, "productmask", &mask, sizeof mask);
if (len == sizeof mask) {
if ((mask & (1 << product_id)) == 0) {
del_node(dev);
/* Have to restart from the beginning. */
dev = NULL;
}
}
}
I had to fix the memcmp bug I mentioned in an earlier posting to allow
searching for a boolean (empty) property.
If anyone cares, below is a trivial patch to expose the del_node()
operation via dt_ops.
Thanks again,
-=] Mike [=-
Index: arch/powerpc/boot/ops.h
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 ops.h
--- arch/powerpc/boot/ops.h 11 Oct 2008 02:51:35 - 1.1.1.1
+++ arch/powerpc/boot/ops.h 18 Oct 2008 02:06:45 -
@@ -40,6 +40,7 @@
const int buflen);
int (*setprop)(const void *phandle, const char *name,
const void *buf, const int buflen);
+ int (*del_node)(const void *phandle);
void *(*get_parent)(const void *phandle);
/* The node must not already exist. */
void *(*create_node)(const void *parent, const char *name);
@@ -124,6 +125,11 @@
return dt_ops.setprop(devp, name, buf, strlen(buf) + 1);
return -1;
+}
+
+static inline int del_node(const void *devp)
+{
+ return dt_ops.del_node ? dt_ops.del_node(devp) : -1;
}
static inline void *get_parent(const char *devp)
Index: arch/powerpc/boot/libfdt-wrapper.c
===
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 libfdt-wrapper.c
--- arch/powerpc/boot/libfdt-wrapper.c 11 Oct 2008 02:51:35 - 1.1.1.1
+++ arch/powerpc/boot/libfdt-wrapper.c 17 Oct 2008 22:08:44 -
@@ -105,6 +105,11 @@
return check_err(rc);
}
+static int fdt_wrapper_del_node(const void *devp)
+{
+ return fdt_del_node(fdt, devp_offset(devp));
+}
+
static void *fdt_wrapper_get_parent(const void *devp)
{
return offset_devp(fdt_parent_offset(fdt, devp_offset(devp)));
@@ -173,6 +178,7 @@
dt_ops.create_node = fdt_wrapper_create_node;
dt_ops.find_node_by_prop_value = fdt_wrapper_find_node_by_prop_value;
dt_ops.find_node_by_compatible = fdt_wrapper_find_node_by_compatible;
+ dt_ops.del_node = fdt_wrapper_del_node;
dt_ops.get_path = fdt_wrapper_get_path;
dt_ops.finalize = fdt_wrapper_finalize;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
4xx 'next' branch updated
Hi All, The follow patches have been added to the 4xx 'next' branch: Josh Boyer (5): powerpc/40x: AMCC PowerPC 405EZ Acadia DTS powerpc/40x: Add AMCC PowerPC 405EZ to cputable powerpc/40x: Add PowerPC 40x simple platform support powerpc/40x: Add cuboot wrapper for Acadia board powerpc/40x: Add PowerPC 405EZ Acadia defconfig Niklaus Giger (1): powerpc/40x: Add support for Netstal HCU4 board Steven A. Falco (1): powerpc/4xx: Add PowerPC 4xx GPIO driver They will sit there over the weekend and then I will probably ask Ben to pull. I have one more patch (Ben's PCI ISA thing) that I'll probably include for 2.6.28 (aside from bug fixes and defconfig updates.) The rest I'll target for 2.6.29. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: remove device_type = "board-control"
We don't want to encourage the bogus device_type usage.
The device type isn't used in the code, so we can simply remove it from
the documentation and dts files.
Boards should specify proper compatible entries instead.
Suggested-by: David Gibson <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
On Sat, Oct 11, 2008 at 05:56:18PM +1100, David Gibson wrote:
[...]
> > +Example:
> > +
> > + [EMAIL PROTECTED],0 {
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + device_type = "board-control";
>
> This device_type field should not be used. I know it is in the
> existing samples, which is another bug. But please don't document it
> (and thereby further encourage it).
I didn't forget your comment. ;-) Here is a cleanup patch for
the documentation and dts files.
Documentation/powerpc/dts-bindings/fsl/board.txt |6 +++---
arch/powerpc/boot/dts/mpc832x_mds.dts|2 +-
arch/powerpc/boot/dts/mpc834x_mds.dts|2 +-
arch/powerpc/boot/dts/mpc836x_mds.dts|2 +-
arch/powerpc/boot/dts/mpc8568mds.dts |2 +-
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt
b/Documentation/powerpc/dts-bindings/fsl/board.txt
index e97877f..2bd9888 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -2,13 +2,13 @@
Required properties:
- - device_type : Should be "board-control"
+ - compatible : Should be "fsl,-bcsr"
- reg : Offset and length of the register set for the device
Example:
[EMAIL PROTECTED] {
- device_type = "board-control";
+ compatible = "fsl,mpc8360mds-bcsr";
reg = ;
};
@@ -46,7 +46,7 @@ Example:
[EMAIL PROTECTED],0 {
#address-cells = <1>;
#size-cells = <1>;
- device_type = "board-control";
+ compatible = "fsl,mpc8360mds-bcsr";
reg = <1 0 0x8000>;
ranges = <0 1 0 0x8000>;
diff --git a/arch/powerpc/boot/dts/mpc832x_mds.dts
b/arch/powerpc/boot/dts/mpc832x_mds.dts
index e4cc176..57c595b 100644
--- a/arch/powerpc/boot/dts/mpc832x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc832x_mds.dts
@@ -60,7 +60,7 @@
};
[EMAIL PROTECTED] {
- device_type = "board-control";
+ compatible = "fsl,mpc8323mds-bcsr";
reg = <0xf800 0x8000>;
};
diff --git a/arch/powerpc/boot/dts/mpc834x_mds.dts
b/arch/powerpc/boot/dts/mpc834x_mds.dts
index 04bfde3..c986c54 100644
--- a/arch/powerpc/boot/dts/mpc834x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc834x_mds.dts
@@ -49,7 +49,7 @@
};
[EMAIL PROTECTED] {
- device_type = "board-control";
+ compatible = "fsl,mpc8349mds-bcsr";
reg = <0xe240 0x8000>;
};
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index bdb14ba..98443fc 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -71,7 +71,7 @@
[EMAIL PROTECTED],0 {
#address-cells = <1>;
#size-cells = <1>;
- device_type = "board-control";
+ compatible = "fsl,mpc8360mds-bcsr";
reg = <1 0 0x8000>;
ranges = <0 1 0 0x8000>;
diff --git a/arch/powerpc/boot/dts/mpc8568mds.dts
b/arch/powerpc/boot/dts/mpc8568mds.dts
index a15f103..c80158f 100644
--- a/arch/powerpc/boot/dts/mpc8568mds.dts
+++ b/arch/powerpc/boot/dts/mpc8568mds.dts
@@ -52,7 +52,7 @@
};
[EMAIL PROTECTED] {
- device_type = "board-control";
+ compatible = "fsl,mpc8568mds-bcsr";
reg = <0xf800 0x8000>;
};
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Fwd: finding fuction names]
On Fri, Oct 17, 2008 at 01:06:29PM -0500, Steven Munroe wrote: > Alan can you respond to this. This XLC but I suspect it is common with > GCC and the PPC64 ABI. Indeed, this is due to the ABI. Content-Description: Forwarded message - finding fuction names > To: linuxppc-dev@ozlabs.org > Subject: finding fuction names > From: [EMAIL PROTECTED] > Date: Fri, 17 Oct 2008 11:07:11 -0400 > Cc: [EMAIL PROTECTED] > > /* > > Hi, > >We have code in our product that produces stacktraces. Part of the > implementation of this code runs nm to find all of the entry points in > our libraries. > >Using the 7.0 version of this compiler to compile the simple code below > > xlC_r -c -q64 tt.cxx > nm -C tt.o > U __IBMCPlusPlusExceptionV1 > D test() > T .test() > >Using the 8.0 version of this compiler to compile the simple code below > > xlC_r -c -q64 tt.cxx > nm -C tt.o > U __IBMCPlusPlusExceptionV2 > D test() > > > We grep the nm output for text symbols which are labeled with 'T'. > Not all function names are not labeled as text in objects compiled with > 8.0. > Is there another way to find all of the fuction names in a library or > a compiler switch that will put all fuctions into the text segment ? The PowerPC64 ABI uses function descriptors, stored in the .opd section, a data section. The address of a function is that of its descriptor, which nm correctly shows as a 'D' type symbol. A symbol marking the start of the function code is unnecessary since you can find that from the descriptor, so later compilers omit the "dot" symbol. nm --synthetic will look up the descriptor for you and display fake "dot" symbols marking the start of each function's code. -- Alan Modra Australia Development Lab, IBM ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Fri, Oct 17, 2008 at 01:24:42PM -0700, David Brownell wrote:
> On Thursday 16 October 2008, Anton Vorontsov wrote:
> > +/*
> > + * Platforms can define their own __dev_ versions to glue gpio_chips with
> > the
> > + * architecture-specific code.
> > + */
> > +#ifndef __dev_gpiochip_add
> > +#define __dev_gpiochip_add __dev_gpiochip_add
> > +static inline int __dev_gpiochip_add(struct device *dev,
> > + struct gpio_chip *chip)
> > +{
> > + chip->dev = dev;
> > + return gpiochip_add(chip);
> > +}
> > +#endif /* __dev_gpiochip_add */
>
> This is pretty ugly, especially the implication that *EVERY* gpio_chip
> provider needs modification to use these calls.
Anyway most of them need some modifications to work with OF...
> Surely it would be a lot simpler to just add platform-specific hooks
> to gpiochip_{add,remove}(), [...]
We have printk and dev_printk. kzalloc and devm_kzalloc (though I
aware that devm_ are different than just dev_). So I thought that
dev_gpiochip_* would be logical order of things...
If you don't like it, I can readily implement hooks for
gpiochip_{add,remove}().
Thanks for the comments,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI-E devices not being detected with switch
On Fri, 2008-10-17 at 09:54 -0500, Ayman El-Khashab wrote:
> Benjamin Herrenschmidt wrote:
> > On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote:
> >> Benjamin Herrenschmidt wrote:
> >>> On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote:
> >>>
> >>> Note for people on CC: This is a problem on 460EX on a canyonland
> >>> using the 4x port.
> >>>
> >
> > Ok, can you send me a full dmesg log with "debug" on the kernel
> > command line after adding a #define DEBUG 1 to the top of
> > drivers/pci/probe.c please ? (before the batch of #include).
> >
>
> Yes, it is below. I saw the #define DEBUG 1 turned on these messages
> below, but I am not sure how to verify that I correctly added the
> "debug" to the kernel arguments. (In u-boot I added them to the end
> of the ramargs variable)
Can you try this (untested) patch and send me the resulting dmesg log
(along with whether it helps).
I think I know what the problem is. This isn't the "proper" solution
that should be implemented but it might help with the generic code
detecting that something is wrong and fixing it up.
I'll look at doing something better next week.
The problem I -think- is the bus numbers in the switch don't get reset
by the PCI-E reset below the root complex. Thus when the kernel probes,
it finds non sensical numbers in there that don't fit the range assigned
to the parent bus.
We can force the kernel to renumber everything with a flag but that will
cause problems with the root complex on 4xx due to other considerations
(that we need to fix too, mainly the way we limit config space to a
subset of bus numbers, we need to switch to dynamic fixmap for config
space to solve that).
If my theory is correct, this patch should help the kernel detect that
something is wrong on the switch and reconfigure it.
Cheers,
Ben.
Index: linux-work/drivers/pci/probe.c
===
--- linux-work.orig/drivers/pci/probe.c 2008-10-18 08:10:25.0 +1100
+++ linux-work/drivers/pci/probe.c 2008-10-18 08:14:14.0 +1100
@@ -536,19 +536,27 @@
int is_cardbus = (dev->hdr_type == PCI_HEADER_TYPE_CARDBUS);
u32 buses, i, j = 0;
u16 bctl;
+ int broken = 0;
pci_read_config_dword(dev, PCI_PRIMARY_BUS, &buses);
dev_dbg(&dev->dev, "scanning behind bridge, config %06x, pass %d\n",
buses & 0xff, pass);
+ /* Check if setup is sensible at all */
+ if ((buses & 0xff) != bus->number ||
+ ((buses >> 8) & 0xff) != <= bus->number) {
+ dev_dbg(&dev->dev, "bus configuration doesn't match,
reconfiguring\n");
+ broken = 1;
+ }
+
/* Disable MasterAbortMode during probing to avoid reporting
of bus errors (in some architectures) */
pci_read_config_word(dev, PCI_BRIDGE_CONTROL, &bctl);
pci_write_config_word(dev, PCI_BRIDGE_CONTROL,
bctl & ~PCI_BRIDGE_CTL_MASTER_ABORT);
- if ((buses & 0x00) && !pcibios_assign_all_busses() && !is_cardbus) {
+ if ((buses & 0x00) && !pcibios_assign_all_busses() && !is_cardbus
&& !broken) {
unsigned int cmax, busnr;
/*
* Bus already configured by firmware, process it in the first
@@ -586,7 +594,7 @@
* do in the second pass.
*/
if (!pass) {
- if (pcibios_assign_all_busses())
+ if (pcibios_assign_all_busses() || broken)
/* Temporarily disable forwarding of the
configuration cycles on all bridges in
this bus segment to avoid possible
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add,remove} calls
On Fri, Oct 17, 2008 at 01:25:01PM -0700, David Brownell wrote:
> On Thursday 16 October 2008, Anton Vorontsov wrote:
> > + if (of_gc->chip)
> > + return of_gc->chip;
> > + return &of_gc->gc;
>
> presumably there's a reason not to
>
> of_gc->chip = &of_gc->gc;
Yes, there are two reasons:
1. I need some place to insert the huge comment, which you snipped. ;-)
2. I didn't want to break current users. That is, the line you purpose
("of_gc->chip = &of_gc->gc;") should be inserted to every of_gpio
controller. Most of them use of_mm_gpiochip_add(), so these are easy.
But some (mcu_mpc8349emitx.c) are doing things by themselves.
Thanks,
--
Anton Vorontsov
email: [EMAIL PROTECTED]
irc://irc.freenode.net/bd2
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] igb: add IGB_DCA instead of selecting INTEL_IOATDMA
Add a bool IGB_DCA defined to y if IGB and DCA are enabled, but IGB isn't y
while DCA=m. And thus remove the need to select INTEL_IOATDMA when IGB is
enabled, so that non-x86 architectures can build the igb driver.
Based on work/patch from Brice Goglin <[EMAIL PROTECTED]>
Signed-off-by: Jeff Kirsher <[EMAIL PROTECTED]>
---
drivers/net/Kconfig|5 +
drivers/net/igb/igb_main.c | 32
2 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index ad301ac..588ef13 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -2003,6 +2003,11 @@ config IGB_LRO
If in doubt, say N.
+config IGB_DCA
+ bool "Enable DCA"
+ default y
+ depends on IGB && DCA && !(IGB=y && DCA=m)
+
source "drivers/net/ixp2000/Kconfig"
config MYRI_SBUS
diff --git a/drivers/net/igb/igb_main.c b/drivers/net/igb/igb_main.c
index 53cbeae..2bd3629 100644
--- a/drivers/net/igb/igb_main.c
+++ b/drivers/net/igb/igb_main.c
@@ -41,7 +41,7 @@
#include
#include
#include
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
#include
#endif
#include "igb.h"
@@ -106,11 +106,11 @@ static irqreturn_t igb_msix_other(int irq, void *);
static irqreturn_t igb_msix_rx(int irq, void *);
static irqreturn_t igb_msix_tx(int irq, void *);
static int igb_clean_rx_ring_msix(struct napi_struct *, int);
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
static void igb_update_rx_dca(struct igb_ring *);
static void igb_update_tx_dca(struct igb_ring *);
static void igb_setup_dca(struct igb_adapter *);
-#endif /* CONFIG_DCA */
+#endif /* CONFIG_IGB_DCA */
static bool igb_clean_tx_irq(struct igb_ring *);
static int igb_poll(struct napi_struct *, int);
static bool igb_clean_rx_irq_adv(struct igb_ring *, int *, int);
@@ -131,7 +131,7 @@ static int igb_suspend(struct pci_dev *, pm_message_t);
static int igb_resume(struct pci_dev *);
#endif
static void igb_shutdown(struct pci_dev *);
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
static int igb_notify_dca(struct notifier_block *, unsigned long, void *);
static struct notifier_block dca_notifier = {
.notifier_call = igb_notify_dca,
@@ -207,7 +207,7 @@ static int __init igb_init_module(void)
global_quad_port_a = 0;
ret = pci_register_driver(&igb_driver);
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
dca_register_notify(&dca_notifier);
#endif
return ret;
@@ -223,7 +223,7 @@ module_init(igb_init_module);
**/
static void __exit igb_exit_module(void)
{
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
dca_unregister_notify(&dca_notifier);
#endif
pci_unregister_driver(&igb_driver);
@@ -1260,7 +1260,7 @@ static int __devinit igb_probe(struct pci_dev *pdev,
if (err)
goto err_register;
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
if ((adapter->flags & IGB_FLAG_HAS_DCA) &&
(dca_add_requester(&pdev->dev) == 0)) {
adapter->flags |= IGB_FLAG_DCA_ENABLED;
@@ -1334,7 +1334,7 @@ static void __devexit igb_remove(struct pci_dev *pdev)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct igb_adapter *adapter = netdev_priv(netdev);
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
struct e1000_hw *hw = &adapter->hw;
#endif
@@ -1346,7 +1346,7 @@ static void __devexit igb_remove(struct pci_dev *pdev)
flush_scheduled_work();
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
if (adapter->flags & IGB_FLAG_DCA_ENABLED) {
dev_info(&pdev->dev, "DCA disabled\n");
dca_remove_requester(&pdev->dev);
@@ -3294,7 +3294,7 @@ static irqreturn_t igb_msix_tx(int irq, void *data)
struct igb_adapter *adapter = tx_ring->adapter;
struct e1000_hw *hw = &adapter->hw;
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
if (adapter->flags & IGB_FLAG_DCA_ENABLED)
igb_update_tx_dca(tx_ring);
#endif
@@ -3346,14 +3346,14 @@ static irqreturn_t igb_msix_rx(int irq, void *data)
if (netif_rx_schedule_prep(adapter->netdev, &rx_ring->napi))
__netif_rx_schedule(adapter->netdev, &rx_ring->napi);
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
if (adapter->flags & IGB_FLAG_DCA_ENABLED)
igb_update_rx_dca(rx_ring);
#endif
return IRQ_HANDLED;
}
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
static void igb_update_rx_dca(struct igb_ring *rx_ring)
{
u32 dca_rxctrl;
@@ -3473,7 +3473,7 @@ static int igb_notify_dca(struct notifier_block *nb,
unsigned long event,
return ret_val ? NOTIFY_BAD : NOTIFY_DONE;
}
-#endif /* CONFIG_DCA */
+#endif /* CONFIG_IGB_DCA */
/**
* igb_intr_msi - Interrupt Handler
@@ -3552,13 +3552,13 @@ static int igb_poll(struct napi_struct *napi, int
budget)
int tx_clean_complete, work_done = 0;
/* this poll routine only supports one tx and one rx queue */
-#ifdef CONFIG_DCA
+#ifdef CONFIG_IGB_DCA
if (adapter->flag
RE: Problems with PCI-E devices not being detected with switch
On Fri, 2008-10-17 at 09:54 -0500, Ayman El-Khashab wrote: > Benjamin Herrenschmidt wrote: > > On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote: > >> Benjamin Herrenschmidt wrote: > >>> On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote: > >>> > >>> Note for people on CC: This is a problem on 460EX on a canyonland > >>> using the 4x port. > >>> > > > > Ok, can you send me a full dmesg log with "debug" on the kernel > > command line after adding a #define DEBUG 1 to the top of > > drivers/pci/probe.c please ? (before the batch of #include). > > > > Yes, it is below. I saw the #define DEBUG 1 turned on these messages > below, but I am not sure how to verify that I correctly added the > "debug" to the kernel arguments. (In u-boot I added them to the end > of the ramargs variable) It's ok. "debug" just makes those messages visible on the boot console, 'dmesg' always shows it all. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add, remove} calls
On Thursday 16 October 2008, Anton Vorontsov wrote: > + if (of_gc->chip) > + return of_gc->chip; > + return &of_gc->gc; presumably there's a reason not to of_gc->chip = &of_gc->gc; when this gets set up, so this can always be a simple return of_gc->chip; (and inlined)? Needlessly complex... ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 4/7] gpiolib: implement dev_gpiochip_{add,remove} calls
On Thursday 16 October 2008, Anton Vorontsov wrote:
> +/*
> + * Platforms can define their own __dev_ versions to glue gpio_chips with the
> + * architecture-specific code.
> + */
> +#ifndef __dev_gpiochip_add
> +#define __dev_gpiochip_add __dev_gpiochip_add
> +static inline int __dev_gpiochip_add(struct device *dev,
> + struct gpio_chip *chip)
> +{
> + chip->dev = dev;
> + return gpiochip_add(chip);
> +}
> +#endif /* __dev_gpiochip_add */
This is pretty ugly, especially the implication that *EVERY* gpio_chip
provider needs modification to use these calls.
Surely it would be a lot simpler to just add platform-specific hooks
to gpiochip_{add,remove}(), so that no providers need to be changed??
> +#ifndef __dev_gpiochip_remove
> +#define __dev_gpiochip_remove __dev_gpiochip_remove
> +static inline int __dev_gpiochip_remove(struct device *dev,
> + struct gpio_chip *chip)
> +{
> + return gpiochip_remove(chip);
> +}
> +#endif /* __dev_gpiochip_remove */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-git7 compile error (ppc)
On Oct 17, 2008, at 1:11 PM, Badari Pulavarty wrote: On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote: Hi, I get this following compile error on my ppc box. Let me know if its a known issue. Otherwise, I can figure out whats happening. Thanks, Badari This is due to recent changes to move phys_add_t definition from arch/powerpc/include/asm/types.h to include/linux/types.h. arch/powerpc/include/asm/page.h needs phys_addr_t for CONFIG_RELOCATABLE. Needs fixing.. Thanks, Badari CC arch/powerpc/mm/slb.o In file included from /usr/src/linux-2.6.27/arch/powerpc/include/ asm/mmu-hash64.h:16, from /usr/src/linux-2.6.27/arch/powerpc/include/asm/ mmu.h:7, from /usr/src/linux-2.6.27/arch/powerpc/include/asm/ pgtable.h:7, from arch/powerpc/mm/slb.c:19: /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: error: parse error before "memstart_addr" /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: type defaults to `int' in declaration of `memstart_addr' /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: data definition has no type or storage class /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: error: parse error before "kernstart_addr" /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: type defaults to `int' in declaration of `kernstart_addr' /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: data definition has no type or storage class AS arch/powerpc/lib/string.o CC arch/powerpc/lib/alloc.o CALLarch/powerpc/kernel/systbl_chk.sh CC arch/powerpc/kernel/sysfs.o make[1]: *** [arch/powerpc/mm/slb.o] Error 1 make: *** [arch/powerpc/mm] Error 2 make: *** Waiting for unfinished jobs I've got a patch that seems to address this for me building w/ CONFIG_RELOCATABLE on ppc32/85xx. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
build failure on powerpc with current -git
The current -git fails to build on 64-bit powerpc (failure log below) . Initially I tried using my older toolchain, when I first saw the problem I built a new toolchain with crosstool (gcc 4.1.2 and binutils 2.16.1) and tried again but got the same problem. 2.6.27 doesn't show this problem. Any ideas what's going on and how I can fix it? Thanks, Chris LD vmlinux.o MODPOST vmlinux.o WARNING: modpost: Found 4 section mismatch(es). To see full details build your kernel with: 'make CONFIG_DEBUG_SECTION_MISMATCH=y' GEN .version CHK include/linux/compile.h UPD include/linux/compile.h CC init/version.o LD init/built-in.o LD .tmp_vmlinux1 /opt/crosstool/gcc-4.1.2-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld: BFD 2.16.1 internal error, aborting at /home/cfriesen/crosstool-0.43/build/powerpc64-unknown-linux-gnu/gcc-4.1.2-glibc-2.3.6/binutils-2.16.1/bfd/elflink.c line 6419 in elf_link_output_extsym /opt/crosstool/gcc-4.1.2-glibc-2.3.6/powerpc64-unknown-linux-gnu/bin/powerpc64-unknown-linux-gnu-ld: Please report this bug. make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [sub-make] Error 2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Bug in boot code memcmp with zero length
I noticed, when trying to use, e.g., node = find_node_by_prop_value(prev, "booleanprop", "", 0)) to search for all nodes with a certain boolean property, that memcmp() returns garbage when comparing zero bytes. It should return zero. Index: arch/powerpc/boot/string.S === retrieving revision 1.1.1.1 diff -u -r1.1.1.1 string.S --- arch/powerpc/boot/string.S 11 Oct 2008 02:51:35 - 1.1.1.1 +++ arch/powerpc/boot/string.S 17 Oct 2008 19:11:18 - @@ -235,7 +235,7 @@ .globl memcmp memcmp: cmpwi 0,r5,0 - blelr + ble 2f mtctr r5 addir6,r3,-1 addir4,r4,-1 @@ -243,6 +243,8 @@ lbzur0,1(r4) subf. r3,r0,r3 bdnzt 2,1b + blr +2: li r3,0 blr ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 4/4] powerpc/83xx: add USB Host support for the MPC8360E-RDK boards
Simply add the usb node to support USB host on the MPC8360E-RDK
boards.
Currently U-Boot doesn't fill the clock-frequency property for
timer nodes, so for now we have to fill it manually.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_rdk.dts | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_rdk.dts
b/arch/powerpc/boot/dts/mpc836x_rdk.dts
index decadf3..37b7895 100644
--- a/arch/powerpc/boot/dts/mpc836x_rdk.dts
+++ b/arch/powerpc/boot/dts/mpc836x_rdk.dts
@@ -218,8 +218,23 @@
reg = <0x440 0x40>;
interrupts = <12 13 14 15>;
interrupt-parent = <&qeic>;
- /* filled by u-boot */
- clock-frequency = <0>;
+ clock-frequency = <1>;
+ };
+
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
+ reg = <0x6c0 0x40 0x8b00 0x100>;
+ interrupts = <11>;
+ interrupt-parent = <&qeic>;
+ fsl,fullspeed-clock = "clk21";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&qe_pio_e 20 0 /* SPEED */
+&qe_pio_e 21 1 /* POWER */>;
};
[EMAIL PROTECTED] {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/4] powerpc: add driver for simple GPIO banks
The driver supports very simple GPIO controllers, that is, when a
controller provides just a 'data' register. Such controllers may be
found in various BCSRs (Board's FPGAs used to control board's
switches, LEDs, chip-selects, Ethernet/USB PHY power, etc).
So far we support only 1-byte GPIO banks. Support for other widths may
be implemented when/if needed.
p.s.
To avoid "made up" compatible entries (like compatible = "simple-gpio"),
boards must call the simple_gpiochip_init() to pass the compatible
string.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
Documentation/powerpc/dts-bindings/fsl/board.txt | 30
arch/powerpc/platforms/Kconfig | 10 ++
arch/powerpc/sysdev/Makefile |1 +
arch/powerpc/sysdev/simple_gpio.c| 156 ++
arch/powerpc/sysdev/simple_gpio.h| 13 ++
5 files changed, 210 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/sysdev/simple_gpio.c
create mode 100644 arch/powerpc/sysdev/simple_gpio.h
diff --git a/Documentation/powerpc/dts-bindings/fsl/board.txt
b/Documentation/powerpc/dts-bindings/fsl/board.txt
index 74ae6f1..e97877f 100644
--- a/Documentation/powerpc/dts-bindings/fsl/board.txt
+++ b/Documentation/powerpc/dts-bindings/fsl/board.txt
@@ -27,3 +27,33 @@ Example (MPC8610HPCD):
compatible = "fsl,fpga-pixis";
reg = <0xe800 32>;
};
+
+* Freescale BCSR GPIO banks
+
+Some BCSR registers act as simple GPIO controllers, each such
+register can be represented by the gpio-controller node.
+
+Required properities:
+- compatible : Should be "fsl,-bcsr-gpio";
+- reg : Should contain the address and the lenght of the GPIO bank
+ register;
+- #gpio-cells : Should be two. The first cell is the pin number and the
+ second cell is used to specify optional paramters (currently unused);
+- gpio-controller : Marks the port as GPIO controller.
+
+Example:
+
+ [EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ device_type = "board-control";
+ reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
+ };
diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
index 47e956c..63780c8 100644
--- a/arch/powerpc/platforms/Kconfig
+++ b/arch/powerpc/platforms/Kconfig
@@ -312,4 +312,14 @@ config MPC8xxx_GPIO
Say Y here if you're going to use hardware that connects to the
MPC831x/834x/837x/8572/8610 GPIOs.
+config SIMPLE_GPIO
+ bool "Support for simple, memory-mapped GPIO controllers"
+ depends on PPC
+ select GENERIC_GPIO
+ select ARCH_REQUIRE_GPIOLIB
+ help
+ Say Y here to support simple, memory-mapped GPIO controllers.
+ These are usually BCSRs used to control board's switches, LEDs,
+ chip-selects, Ethernet/USB PHY's power and various other small
+ on-board peripherals.
endmenu
diff --git a/arch/powerpc/sysdev/Makefile b/arch/powerpc/sysdev/Makefile
index a44709a..ee2ddae 100644
--- a/arch/powerpc/sysdev/Makefile
+++ b/arch/powerpc/sysdev/Makefile
@@ -34,6 +34,7 @@ obj-$(CONFIG_4xx) += uic.o
obj-$(CONFIG_4xx_SOC) += ppc4xx_soc.o
obj-$(CONFIG_XILINX_VIRTEX)+= xilinx_intc.o
obj-$(CONFIG_OF_RTC) += of_rtc.o
+obj-$(CONFIG_SIMPLE_GPIO) += simple_gpio.o
ifeq ($(CONFIG_PCI),y)
obj-$(CONFIG_4xx) += ppc4xx_pci.o
endif
diff --git a/arch/powerpc/sysdev/simple_gpio.c
b/arch/powerpc/sysdev/simple_gpio.c
new file mode 100644
index 000..d62c85a
--- /dev/null
+++ b/arch/powerpc/sysdev/simple_gpio.c
@@ -0,0 +1,156 @@
+/*
+ * Simple Memory-Mapped GPIOs
+ *
+ * Copyright (c) MontaVista Software, Inc. 2008.
+ *
+ * Author: Anton Vorontsov <[EMAIL PROTECTED]>
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "simple_gpio.h"
+
+struct u8_gpio_chip {
+ struct of_mm_gpio_chip mm_gc;
+ spinlock_t lock;
+
+ /* shadowed data register to clear/set bits safely */
+ u8 data;
+};
+
+static struct u8_gpio_chip *to_u8_gpio_chip(struct of_mm_gpio_chip *mm_gc)
+{
+ return container_of(mm_gc, struct u8_gpio_chip, mm_gc);
+}
+
+static u8 u8_pin2mask(unsigned int pin)
+{
+ return 1 << (8 - 1 - pin);
+}
+
+static int u8_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct of_mm
[PATCH 3/4] powerpc/83xx: add USB Host/Gadget support for the MPC8360E-MDS boards
- Update the device tree per QE USB bindings;
- Add timer (FSL GTM) node;
- Add gpio-controller node for BCSR13 bank (GPIOs on that bank
are used to control the USB transceiver);
- Set up other BCSR registers;
- Configure the QE Par IO.
The work is loosely based on Li Yang's patch[1], which is used
to support peripheral mode only.
[1] http://ozlabs.org/pipermail/linuxppc-dev/2008-August/061357.html
The s-o-b line of the original patch preserved here.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 43 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 52 -
2 files changed, 92 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc836x_mds.dts
b/arch/powerpc/boot/dts/mpc836x_mds.dts
index 66a12d2..bdb14ba 100644
--- a/arch/powerpc/boot/dts/mpc836x_mds.dts
+++ b/arch/powerpc/boot/dts/mpc836x_mds.dts
@@ -69,8 +69,18 @@
};
[EMAIL PROTECTED],0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
device_type = "board-control";
reg = <1 0 0x8000>;
+ ranges = <0 1 0 0x8000>;
+
+ bcsr13: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360mds-bcsr-gpio";
+ reg = <0xd 1>;
+ gpio-controller;
+ };
};
};
@@ -195,10 +205,21 @@
};
[EMAIL PROTECTED] {
+ #address-cells = <1>;
+ #size-cells = <1>;
reg = <0x1400 0x100>;
+ ranges = <0 0x1400 0x100>;
device_type = "par_io";
num-ports = <7>;
+ qe_pio_b: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mpc8360-qe-pario-bank",
+"fsl,mpc8323-qe-pario-bank";
+ reg = <0x18 0x18>;
+ gpio-controller;
+ };
+
pio1: [EMAIL PROTECTED] {
pio-map = <
/* port pin dir open_drain assignment has_irq */
@@ -282,6 +303,15 @@
};
};
+ [EMAIL PROTECTED] {
+ compatible = "fsl,mpc8360-qe-gtm",
+"fsl,qe-gtm", "fsl,gtm";
+ reg = <0x440 0x40>;
+ clock-frequency = <13200>;
+ interrupts = <12 13 14 15>;
+ interrupt-parent = <&qeic>;
+ };
+
[EMAIL PROTECTED] {
cell-index = <0>;
compatible = "fsl,spi";
@@ -301,11 +331,20 @@
};
[EMAIL PROTECTED] {
- compatible = "qe_udc";
+ compatible = "fsl,mpc8360-qe-usb",
+"fsl,mpc8323-qe-usb";
reg = <0x6c0 0x40 0x8b00 0x100>;
interrupts = <11>;
interrupt-parent = <&qeic>;
- mode = "slave";
+ fsl,fullspeed-clock = "clk21";
+ fsl,lowspeed-clock = "brg9";
+ gpios = <&qe_pio_b 2 0 /* USBOE */
+&qe_pio_b 3 0 /* USBTP */
+&qe_pio_b 8 0 /* USBTN */
+&qe_pio_b 9 0 /* USBRP */
+&qe_pio_b 11 0 /* USBRN */
+&bcsr135 0 /* SPEED */
+&bcsr134 1>; /* POWER */
};
enet0: [EMAIL PROTECTED] {
diff --git a/arch/powerpc/platforms/83xx/mpc836x_mds.c
b/arch/powerpc/platforms/83xx/mpc836x_mds.c
index 9d46e5b..4e69f7b 100644
--- a/arch/powerpc/platforms/83xx/mpc836x_mds.c
+++ b/arch/powerpc/platforms/83xx/mpc836x_mds.c
@@ -43,6 +43,7 @@
#include
#include
#include
+#include
#include
#include
@@ -127,9 +128,58 @@ static void __init mpc836x_mds_setup_arch(void)
iounmap(immap);
}
- iounmap(bcsr_regs);
of_node_put(np);
}
+#ifdef CONFIG_QE_USB
+ np = of_find_compatible_node(NULL, NULL, "fsl,mpc8323-qe-usb");
+ if (np) {
+ const char *mode = of_get_property(np, "mode", NULL);
+
+ par_io_config_pin(1, 2, 1, 0, 3, 0); /* USBOE */
+ par_io_config_pin(1, 3, 1, 0, 3, 0); /* USBTP */
+
[PATCH 1/4] powerpc/QE: implement QE Pin Multiplexing API
With this API we're able to set a QE pin to the GPIO mode or a dedicated
peripheral function.
The API relies on the fact that QE gpio controllers are registered. If
they aren't, the API won't work (gracefully though).
There is one caveat though: if anybody occupied the node->data before us,
or overwrote it, then bad things will happen. Luckily this is all in the
platform code that we fully control, so this should never happen.
I could implement more checks (for example we could create a list of
successfully registered QE controllers, and compare the node->data in the
qe_pin_request()), but this is unneeded if nobody is going to do silly
things behind our back.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/qe.h |9 ++
arch/powerpc/sysdev/qe_lib/gpio.c | 195 +
2 files changed, 204 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h
index edee15d..31ddbc9 100644
--- a/arch/powerpc/include/asm/qe.h
+++ b/arch/powerpc/include/asm/qe.h
@@ -112,6 +112,15 @@ extern int par_io_config_pin(u8 port, u8 pin, int dir, int
open_drain,
int assignment, int has_irq);
extern int par_io_data_set(u8 port, u8 pin, u8 val);
+/*
+ * Pin multiplexing functions.
+ */
+struct qe_pin;
+extern struct qe_pin *qe_pin_request(struct device_node *np, int index);
+extern void qe_pin_free(struct qe_pin *qe_pin);
+extern void qe_pin_set_gpio(struct qe_pin *qe_pin);
+extern void qe_pin_set_dedicated(struct qe_pin *pin);
+
/* QE internal API */
int qe_issue_cmd(u32 cmd, u32 device, u8 mcn_protocol, u32 cmd_input);
enum qe_clock qe_clock_source(const char *source);
diff --git a/arch/powerpc/sysdev/qe_lib/gpio.c
b/arch/powerpc/sysdev/qe_lib/gpio.c
index 8e5a0bc..7f10b18 100644
--- a/arch/powerpc/sysdev/qe_lib/gpio.c
+++ b/arch/powerpc/sysdev/qe_lib/gpio.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -24,8 +25,14 @@ struct qe_gpio_chip {
struct of_mm_gpio_chip mm_gc;
spinlock_t lock;
+ unsigned long pin_flags[QE_PIO_PINS];
+#define QE_PIN_REQUESTED 0
+
/* shadowed data register to clear/set bits safely */
u32 cpdata;
+
+ /* saved_regs used to restore dedicated functions */
+ struct qe_pio_regs saved_regs;
};
static inline struct qe_gpio_chip *
@@ -40,6 +47,12 @@ static void qe_gpio_save_regs(struct of_mm_gpio_chip *mm_gc)
struct qe_pio_regs __iomem *regs = mm_gc->regs;
qe_gc->cpdata = in_be32(®s->cpdata);
+ qe_gc->saved_regs.cpdata = qe_gc->cpdata;
+ qe_gc->saved_regs.cpdir1 = in_be32(®s->cpdir1);
+ qe_gc->saved_regs.cpdir2 = in_be32(®s->cpdir2);
+ qe_gc->saved_regs.cppar1 = in_be32(®s->cppar1);
+ qe_gc->saved_regs.cppar2 = in_be32(®s->cppar2);
+ qe_gc->saved_regs.cpodr = in_be32(®s->cpodr);
}
static int qe_gpio_get(struct gpio_chip *gc, unsigned int gpio)
@@ -103,6 +116,188 @@ static int qe_gpio_dir_out(struct gpio_chip *gc, unsigned
int gpio, int val)
return 0;
}
+struct qe_pin {
+ /*
+* The qe_gpio_chip name is unfortunate, we should change that to
+* something like qe_pio_controller. Someday.
+*/
+ struct qe_gpio_chip *controller;
+ int num;
+};
+
+/**
+ * qe_pin_request - Request a QE pin
+ * @np:device node to get a pin from
+ * @index: index of a pin in the device tree
+ * Context:non-atomic
+ *
+ * This function return qe_pin so that you could use it with the rest of
+ * the QE Pin Multiplexing API.
+ */
+struct qe_pin *qe_pin_request(struct device_node *np, int index)
+{
+ struct qe_pin *qe_pin;
+ struct device_node *gc;
+ struct of_gpio_chip *of_gc = NULL;
+ struct of_mm_gpio_chip *mm_gc;
+ struct qe_gpio_chip *qe_gc;
+ int err;
+ int size;
+ const void *gpio_spec;
+ const u32 *gpio_cells;
+ unsigned long flags;
+
+ qe_pin = kzalloc(sizeof(*qe_pin), GFP_KERNEL);
+ if (!qe_pin) {
+ pr_debug("%s: can't allocate memory\n", __func__);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ err = of_parse_phandles_with_args(np, "gpios", "#gpio-cells", index,
+ &gc, &gpio_spec);
+ if (err) {
+ pr_debug("%s: can't parse gpios property\n", __func__);
+ goto err0;
+ }
+
+ if (!of_device_is_compatible(gc, "fsl,mpc8323-qe-pario-bank")) {
+ pr_debug("%s: tried to get a non-qe pin\n", __func__);
+ err = -EINVAL;
+ goto err1;
+ }
+
+ of_gc = gc->data;
+ if (!of_gc) {
+ pr_debug("%s: gpio controller %s isn't registered\n",
+np->full_name, gc->full_name);
+ err = -ENODEV;
+ goto err1;
+ }
+
+ gpio_cells = of_get_property(gc, "#gpi
[PATCH 0/4] Few patches needed to support QE USB on MPC8360E-{MDS,RDK} boards
Hi Kumar, I'm resending the QE USB patches, the old ones started to cause rejects. Could you apply them for 2.6.28? Especially the first patch, since it is holding the FHCI driver. I still hope that Greg would apply the driver post -rc1. ;-) Thanks! -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] powerpc/83xx: add support for MCU on 8349emitx, 837xrdb and 8315erdb boards
MCU is an external Freescale MC9S08QG8 microcontroller, mainly used to
provide soft power-off function, but also exports two GPIOs (wired to
the LEDs and also available from the external headers).
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8315erdb.dts |8
arch/powerpc/boot/dts/mpc8349emitx.dts |8
arch/powerpc/boot/dts/mpc8377_rdb.dts |8
arch/powerpc/boot/dts/mpc8378_rdb.dts |8
arch/powerpc/boot/dts/mpc8379_rdb.dts |8
5 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8315erdb.dts
b/arch/powerpc/boot/dts/mpc8315erdb.dts
index 7449e54..6b85067 100644
--- a/arch/powerpc/boot/dts/mpc8315erdb.dts
+++ b/arch/powerpc/boot/dts/mpc8315erdb.dts
@@ -121,6 +121,14 @@
compatible = "dallas,ds1339";
reg = <0x68>;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8315erdb",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 7fc5414..4bdbaf4 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -91,6 +91,14 @@
interrupts = <18 0x8>;
interrupt-parent = <&ipic>;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8349emitx",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8377_rdb.dts
b/arch/powerpc/boot/dts/mpc8377_rdb.dts
index 53191ba..435ef3d 100644
--- a/arch/powerpc/boot/dts/mpc8377_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8377_rdb.dts
@@ -121,6 +121,14 @@
compatible = "dallas,ds1339";
reg = <0x68>;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8377erdb",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8378_rdb.dts
b/arch/powerpc/boot/dts/mpc8378_rdb.dts
index 4a09153..b11e68f 100644
--- a/arch/powerpc/boot/dts/mpc8378_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8378_rdb.dts
@@ -121,6 +121,14 @@
compatible = "dallas,ds1339";
reg = <0x68>;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8378erdb",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8379_rdb.dts
b/arch/powerpc/boot/dts/mpc8379_rdb.dts
index bbd884a..337af6e 100644
--- a/arch/powerpc/boot/dts/mpc8379_rdb.dts
+++ b/arch/powerpc/boot/dts/mpc8379_rdb.dts
@@ -121,6 +121,14 @@
compatible = "dallas,ds1339";
reg = <0x68>;
};
+
+ mcu_pio: [EMAIL PROTECTED] {
+ #gpio-cells = <2>;
+ compatible = "fsl,mc9s08qg8-mpc8379erdb",
+"fsl,mcu-mpc8349emitx";
+ reg = <0x0a>;
+ gpio-controller;
+ };
};
[EMAIL PROTECTED] {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] powerpc/83xx: add DS1339 RTC support for MPC8349E-mITX boards
The RTC is sitting on the I2C2 bus at address 0x68. RTC interrupt signal
is connected to the IPIC's EXT2 interrupt line, the line is shared with
Vitesse 8201 Ethernet PHY.
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8349emitx.dts |8
arch/powerpc/boot/dts/mpc8349emitxgp.dts |8
2 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc8349emitx.dts
b/arch/powerpc/boot/dts/mpc8349emitx.dts
index 5cedf37..7fc5414 100644
--- a/arch/powerpc/boot/dts/mpc8349emitx.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitx.dts
@@ -83,6 +83,14 @@
interrupts = <15 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ interrupts = <18 0x8>;
+ interrupt-parent = <&ipic>;
+ };
};
[EMAIL PROTECTED] {
diff --git a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
index 81ae1d3..fa40647 100644
--- a/arch/powerpc/boot/dts/mpc8349emitxgp.dts
+++ b/arch/powerpc/boot/dts/mpc8349emitxgp.dts
@@ -81,6 +81,14 @@
interrupts = <15 0x8>;
interrupt-parent = <&ipic>;
dfsrr;
+
+ [EMAIL PROTECTED] {
+ device_type = "rtc";
+ compatible = "dallas,ds1339";
+ reg = <0x68>;
+ interrupts = <18 0x8>;
+ interrupt-parent = <&ipic>;
+ };
};
[EMAIL PROTECTED] {
--
1.5.6.3
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 2.6.27-git7 compile error (ppc)
On Fri, 2008-10-17 at 10:47 -0700, Badari Pulavarty wrote: > Hi, > > I get this following compile error on my ppc box. > > Let me know if its a known issue. Otherwise, I can figure out > whats happening. > > Thanks, > Badari This is due to recent changes to move phys_add_t definition from arch/powerpc/include/asm/types.h to include/linux/types.h. arch/powerpc/include/asm/page.h needs phys_addr_t for CONFIG_RELOCATABLE. Needs fixing.. Thanks, Badari > > CC arch/powerpc/mm/slb.o > In file included from > /usr/src/linux-2.6.27/arch/powerpc/include/asm/mmu-hash64.h:16, > from /usr/src/linux-2.6.27/arch/powerpc/include/asm/mmu.h:7, > from > /usr/src/linux-2.6.27/arch/powerpc/include/asm/pgtable.h:7, > from arch/powerpc/mm/slb.c:19: > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: error: parse error > before "memstart_addr" > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: type > defaults to `int' in declaration of `memstart_addr' > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: data > definition has no type or storage class > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: error: parse error > before "kernstart_addr" > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: type > defaults to `int' in declaration of `kernstart_addr' > /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: data > definition has no type or storage class > AS arch/powerpc/lib/string.o > CC arch/powerpc/lib/alloc.o > CALLarch/powerpc/kernel/systbl_chk.sh > CC arch/powerpc/kernel/sysfs.o > make[1]: *** [arch/powerpc/mm/slb.o] Error 1 > make: *** [arch/powerpc/mm] Error 2 > make: *** Waiting for unfinished jobs > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.27-git7 compile error (ppc)
Hi, I get this following compile error on my ppc box. Let me know if its a known issue. Otherwise, I can figure out whats happening. Thanks, Badari CC arch/powerpc/mm/slb.o In file included from /usr/src/linux-2.6.27/arch/powerpc/include/asm/mmu-hash64.h:16, from /usr/src/linux-2.6.27/arch/powerpc/include/asm/mmu.h:7, from /usr/src/linux-2.6.27/arch/powerpc/include/asm/pgtable.h:7, from arch/powerpc/mm/slb.c:19: /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: error: parse error before "memstart_addr" /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: type defaults to `int' in declaration of `memstart_addr' /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:76: warning: data definition has no type or storage class /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: error: parse error before "kernstart_addr" /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: type defaults to `int' in declaration of `kernstart_addr' /usr/src/linux-2.6.27/arch/powerpc/include/asm/page.h:77: warning: data definition has no type or storage class AS arch/powerpc/lib/string.o CC arch/powerpc/lib/alloc.o CALLarch/powerpc/kernel/systbl_chk.sh CC arch/powerpc/kernel/sysfs.o make[1]: *** [arch/powerpc/mm/slb.o] Error 1 make: *** [arch/powerpc/mm] Error 2 make: *** Waiting for unfinished jobs ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/7 RFC] Handle I2C GPIO controllers with the OF (was: pca9539 I2C gpio expander)
Anton Vorontsov wrote:
> Hi all,
>
> Recently there was a question about I2C GPIO controllers and how should
> we handle them with the OpenFirmware and such.
>
> Here is the attempt to "connect" I2C GPIO controllers to the
> "OpenFirmware" device tree, without writing an OF-specific bindings
> for each driver.
>
> The salt is in these two patches:
>
> [PATCH 3/7] of: fill the archdata for I2C devices
> ^ Here we're storing the device tree node into the I2C device.
>
> [PATCH 5/7] of/gpio: implement of_dev_gpiochip_{add,remove} calls
> ^ And here we extracting the the stored node to put the registered
> of_gpio_chip into that node.
>
>
> How does it look?
I've just tested this with a pca9539 chip attached to my Sequoia board,
and it works perfectly for me. I don't have the mcu_mpc8349emitx.c file
in my tree, so I was not able to apply part 7 of 7, but the rest looks
fine. Thanks for doing this.
Acked by: Steve Falco <[EMAIL PROTECTED]>
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
finding fuction names
/*
Hi,
We have code in our product that produces stacktraces. Part of the
implementation of this code runs nm to find all of the entry points in
our libraries.
Using the 7.0 version of this compiler to compile the simple code below
xlC_r -c -q64 tt.cxx
nm -C tt.o
U __IBMCPlusPlusExceptionV1
D test()
T .test()
Using the 8.0 version of this compiler to compile the simple code below
xlC_r -c -q64 tt.cxx
nm -C tt.o
U __IBMCPlusPlusExceptionV2
D test()
We grep the nm output for text symbols which are labeled with 'T'.
Not all function names are not labeled as text in objects compiled with
8.0.
Is there another way to find all of the fuction names in a library or
a compiler switch that will put all fuctions into the text segment ?
thanks,
Tom
*/
int test()
{
return 1;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/2] powerpc: add 16K/64K pages support for the 44x PPC32 architectures.
On Wed, Oct 15, 2008 at 7:22 PM, Ilya Yanok <[EMAIL PROTECTED]> wrote: > This patch adds support for page sizes bigger than 4K (16K/64K) on > PPC 44x. > This patch looks good to me. Seems that all the review comments have been incorporated. Josh, it would be great if this patch is pulled into the mainline kernel. I have seen significant performance improvement with RAID0/5 by using 64K pages. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Oops in during system run
On Fri, Oct 17, 2008 at 03:49:12PM +0530, Sreejith wrote: > This is a peculiar Oops we are encountering during the running of our board > (sh4) architecture So why are you posting to powerpc lists? > PC : 844240f8 SP : 88d1ff44 SR : 400080f0 TEA : c0169d64Tainted: P With proprietary modules, too. > Give you valuable suggestions!! Debug the code? Switch to powerpc? :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
* Nate Case | 2008-10-17 09:02:11 [-0500]: >On Wed, 2008-10-15 at 16:43 +0200, Sebastian Andrzej Siewior wrote: >> With this patch it compiles and boots fine. >> The option -mabi=no-spe is not required. > >Please don't accept this patch yet. My past testing showed that >"-mabi=no-spe" was required for my toolchain. I'll go back and double >check though. Okay. Here my compiler details: | powerpc-linux-gnuspe-gcc -v | Using built-in specs. | Target: powerpc-linux-gnuspe | Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.1-9' | --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs | --enable-languages=c,c++,obj-c++ --prefix=/usr --enable-shared | --with-system-zlib --libexecdir=/usr/lib --without-included-gettext | --enable-threads=posix --enable-nls | --with-gxx-include-dir=/usr/powerpc-linux-gnuspe/include/c++/4.3.1 | --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug | --disable-multilib --disable-multilib --with-cpu=8540 | --enable-e500_double --with-long-double-128 --enable-checking=release | --program-prefix=powerpc-linux-gnuspe- | --includedir=/usr/powerpc-linux-gnuspe/include --build=i486-linux-gnu | --host=i486-linux-gnu --target=powerpc-linux-gnuspe | Thread model: posix | gcc version 4.3.1 (Debian 4.3.1-9) ths told me that we need all three options in this order because of how they interact with gcc's internal flags. >- Nate Case <[EMAIL PROTECTED]> Sebastian ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: Problems with PCI-E devices not being detected with switch
Benjamin Herrenschmidt wrote: > On Thu, 2008-10-16 at 10:01 -0500, Ayman El-Khashab wrote: >> Benjamin Herrenschmidt wrote: >>> On Wed, 2008-10-15 at 10:47 -0500, Ayman El-Khashab wrote: >>> >>> Note for people on CC: This is a problem on 460EX on a canyonland >>> using the 4x port. >>> > > Ok, can you send me a full dmesg log with "debug" on the kernel > command line after adding a #define DEBUG 1 to the top of > drivers/pci/probe.c please ? (before the batch of #include). > Yes, it is below. I saw the #define DEBUG 1 turned on these messages below, but I am not sure how to verify that I correctly added the "debug" to the kernel arguments. (In u-boot I added them to the end of the ramargs variable) thanks, - ame # dmesg Linux version 2.6.27-01160-gc08fd34-dirty ([EMAIL PROTECTED]) (gcc version 4.2.2) #11 Fri Oct 17 09:32:16 CDT 2008 Found initrd at 0xc6cd5000:0xc6fffbc7 Found legacy serial port 0 for /plb/opb/[EMAIL PROTECTED] mem=4ef600300, taddr=4ef600300, irq=0, clk=7407407, speed=0 Found legacy serial port 1 for /plb/opb/[EMAIL PROTECTED] mem=4ef600400, taddr=4ef600400, irq=0, clk=7407407, speed=0 Found legacy serial port 2 for /plb/opb/[EMAIL PROTECTED] mem=4ef600500, taddr=4ef600500, irq=0, clk=7407407, speed=0 Found legacy serial port 3 for /plb/opb/[EMAIL PROTECTED] mem=4ef600600, taddr=4ef600600, irq=0, clk=7407407, speed=0 Top of RAM: 0x2000, Total RAM: 0x2000 Memory hole size: 0MB Zone PFN ranges: DMA 0x -> 0x0002 Normal 0x0002 -> 0x0002 HighMem 0x0002 -> 0x0002 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0x -> 0x0002 On node 0 totalpages: 131072 free_area_init_node: node 0, pgdat c0344a78, node_mem_map c0372000 DMA zone: 130048 pages, LIFO batch:31 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: ramdisk_size=65536 root=/dev/ram rw debug ip=169.254.0.102: 169.254.0.100:169.254.0.100:255.255.255.0:tanosx:eth0:off panic=1 console=ttyS0, 115200 UIC0 (32 IRQ sources) at DCR 0xc0 UIC1 (32 IRQ sources) at DCR 0xd0 UIC2 (32 IRQ sources) at DCR 0xe0 UIC3 (32 IRQ sources) at DCR 0xf0 PID hash table entries: 2048 (order: 11, 8192 bytes) time_init: decrementer frequency = 800.10 MHz time_init: processor frequency = 800.10 MHz clocksource: timebase mult[50] shift[22] registered clockevent: decrementer mult[] shift[16] cpu[0] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) High memory: 0k Memory: 512640k/524288k available (3228k kernel code, 11320k reserved, 124k data , 138k bss, 160k init) SLUB: Genslabs=10, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 Calibrating delay loop... 1597.44 BogoMIPS (lpj=3194880) Mount-cache hash table entries: 512 net_namespace: 288 bytes NET: Registered protocol family 16 256k L2-cache enabled PCIE0: Checking link... PCIE0: No device detected. PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e..0x000e7fff -> 0x8000 IO 0x000f8000..0x000f8000 -> 0x 4xx PCI DMA offset set to 0x PCIE0: successfully set as endpoint PCIE1: Checking link... PCIE1: Device detected, waiting for link... PCIE1: link is up ! PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000e8000..0x000e -> 0x8000 IO 0x000f8001..0x000f8001 -> 0x 4xx PCI DMA offset set to 0x PCIE1: successfully set as root-complex PCI host bridge /plb/[EMAIL PROTECTED] (primary) ranges: MEM 0x000d8000..0x000d -> 0x8000 IO 0x000c0800..0x000c0800 -> 0x 4xx PCI DMA offset set to 0x PCI: Probing PCI hardware PCI: Scanning bus :40 pci :40:00.0: found [eee0/fed0] class 000b20 header type 00 PCI: :40:00.0 reg 10 64bit mmio: [0, 1ff] PCI: Hiding 4xx host bridge resources :40:00.0 PCI: Fixups for bus :40 PCI: Bus scan for :40 returning with max=40 PCI: Scanning bus 0001:80 pci 0001:80:00.0: found [aaa1/bed1] class 000604 header type 01 PCI: 0001:80:00.0 reg 10 32bit mmio: [0, 7fff] PCI: Hiding 4xx host bridge resources 0001:80:00.0 PCI: Fixups for bus 0001:80 pci 0001:80:00.0: scanning behind bridge, config bf8180, pass 0 PCI: Scanning bus 0001:81 pci 0001:81:00.0: found [10b5/8509] class 000604 header type 01 PCI: 0001:81:00.0 reg 10 32bit mmio: [b800, b801] pci 0001:81:00.0: PME# supported from D0 D3hot D3cold pci 0001:81:00.0: PME# disabled PCI: Fixups for bus 0001:81 PCI: bridge 0001:80:00.0 io port: [0, fff] PCI: bridge 0001:80:00.0 32bit mmio: [b800, b81f] pci 0001:81:00.0: scanning behind bridge, config 060201, pass 0 PCI: Scanning bus 0001:02 pci 0001:02:00.0: found [8201/3e00] class 0091ed header type 48 pci 0001:02:00.0: unknown header type 48, ignoring device pci
Re: [PATCH] powerpc: enforce a non-spe kernel build even on broken compilers
On Wed, 2008-10-15 at 16:43 +0200, Sebastian Andrzej Siewior wrote: > With this patch it compiles and boots fine. > The option -mabi=no-spe is not required. Please don't accept this patch yet. My past testing showed that "-mabi=no-spe" was required for my toolchain. I'll go back and double check though. - Nate Case <[EMAIL PROTECTED]> ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Loadable module crashes at kernel stack overflow or machine check
Ganesh Kumar N M wrote: *Hi All,* ** *I'm working on MPC860 with Montavista linux 2.4.18* *We have a Linux kernel loadable module which on loading* *panicks after some random time say 8 hours, 4 hours or so* *the oops outputs say either machine check exception or * *kernel stack overflow (randomly both show up) a**re as below:* I don't know for sure what could be causing your problem. I can only suggest some patches that have helped us in the past. I'm not familiar with Montavista's kernel versions; but I know our 2.4.24 kernel did not have the 'separate I-TLB error and miss handling' patch ( http://ozlabs.org/pipermail/linuxppc-embedded/2005-January/016382.html ) which caused our applications to segfault for not apparent reason. I also suggest applying the CPU15 fix ( http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commit;h=baf9a6caca75b1f338ae370669e5882809000164 and http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commit;h=3ad403717f1d9c6a09ec41a5b016ac5245591122 ) and enabling it temporarily to see if the problem could be the unlucky placement of a branch instruction at the end of a page; but evaluate the performance of your application carefully if you are considering running production code with the patch enabled as it introduces significant overhead. Regards, Ben Gardiner Nanometrics Seismological Instruments 250 Herzberg Rd., Kanata, ON, CA, K2K 2A1 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fix new MAL feature handling
On Fri, 17 Oct 2008 14:56:52 +0200 Arnd Bergmann <[EMAIL PROTECTED]> wrote: > On Thursday 16 October 2008, Josh Boyer wrote: > > +#ifdef CONFIG_PPC_DCR_NATIVE > > if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT)) > > mtdcri(SDR0, DCRN_SDR_ICINTSTAT, > > (mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | > > ICINTSTAT_ICTX)); > > +#endif > > > > So what if you have a mmio based DRC implementation and still want to use > this feature? You have to have hardware that does that. When it exists, we can probably worry about it. Hopefully that will never happen. (Axon is an abomination that should not be repeated.) > I guess you really should use dcr_read/dcr_write here instead of mtdcr/mfdcr. We can look at that. It's not going to be high on my TODO list at the moment though. (hint, there are other places that do the same thing here and they should all be cleaned up if we're going to bother.) josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibm_newemac: Fix new MAL feature handling
On Thursday 16 October 2008, Josh Boyer wrote: > +#ifdef CONFIG_PPC_DCR_NATIVE > if (mal_has_feature(mal, MAL_FTR_CLEAR_ICINTSTAT)) > mtdcri(SDR0, DCRN_SDR_ICINTSTAT, > (mfdcri(SDR0, DCRN_SDR_ICINTSTAT) | > ICINTSTAT_ICTX)); > +#endif > So what if you have a mmio based DRC implementation and still want to use this feature? I guess you really should use dcr_read/dcr_write here instead of mtdcr/mfdcr. Arnd <>< ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] IB/ehca: Fix problem with max number of QPs and CQs in systems with different adapters
Because ehca adapters can differ in the maximum number of QPs and CQs
we have to save the maximum number of these ressources per adapter and not
globally per ehca driver. This fix introduces 2 new members to the shca
structure to store the maximum value for QPs and CQs per adapter.
The module parameters are now used as initial values for those variables.
If a user selects an invalid number of CQs or QPs we don't print an error any
longer, instead we will inform the user with a warning and set the values to
the respective maximum supported by the HW.
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_classes.h |2 +
drivers/infiniband/hw/ehca/ehca_cq.c |4 +-
drivers/infiniband/hw/ehca/ehca_main.c| 35
drivers/infiniband/hw/ehca/ehca_qp.c |4 +-
4 files changed, 26 insertions(+), 19 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h
b/drivers/infiniband/hw/ehca/ehca_classes.h
index 5d7b785..4df887a 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -128,6 +128,8 @@ struct ehca_shca {
/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
u32 hca_cap_mr_pgsize;
int max_mtu;
+ int max_num_qps;
+ int max_num_cqs;
atomic_t num_cqs;
atomic_t num_qps;
};
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c
b/drivers/infiniband/hw/ehca/ehca_cq.c
index 33647a9..2f4c28a 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,9 +132,9 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int
cqe, int comp_vector,
if (cqe >= 0x - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
- if (!atomic_add_unless(&shca->num_cqs, 1, ehca_max_cq)) {
+ if (!atomic_add_unless(&shca->num_cqs, 1, shca->max_num_cqs)) {
ehca_err(device, "Unable to create CQ, max number of %i "
- "CQs reached.", ehca_max_cq);
+ "CQs reached.", shca->max_num_cqs);
ehca_err(device, "To increase the maximum number of CQs "
"use the number_of_cqs module parameter.\n");
return ERR_PTR(-ENOSPC);
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c
b/drivers/infiniband/hw/ehca/ehca_main.c
index 598844d..086959a 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -366,22 +366,23 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
/* Set maximum number of CQs and QPs to calculate EQ size */
- if (ehca_max_qp == -1)
- ehca_max_qp = min_t(int, rblock->max_qp, EHCA_MAX_NUM_QUEUES);
- else if (ehca_max_qp < 1 || ehca_max_qp > rblock->max_qp) {
- ehca_gen_err("Requested number of QPs is out of range (1 - %i) "
- "specified by HW", rblock->max_qp);
- ret = -EINVAL;
- goto sense_attributes1;
+ if (shca->max_num_qps == -1)
+ shca->max_num_qps = min_t(int, rblock->max_qp,
+ EHCA_MAX_NUM_QUEUES);
+ else if (shca->max_num_qps < 1 || shca->max_num_qps > rblock->max_qp) {
+ ehca_gen_warn("The requested number of QPs is out of range "
+ "(1 - %i) specified by HW. Value is set to %i",
+ rblock->max_qp, rblock->max_qp);
+ shca->max_num_qps = rblock->max_qp;
}
- if (ehca_max_cq == -1)
- ehca_max_cq = min_t(int, rblock->max_cq, EHCA_MAX_NUM_QUEUES);
- else if (ehca_max_cq < 1 || ehca_max_cq > rblock->max_cq) {
- ehca_gen_err("Requested number of CQs is out of range (1 - %i) "
- "specified by HW", rblock->max_cq);
- ret = -EINVAL;
- goto sense_attributes1;
+ if (shca->max_num_cqs == -1)
+ shca->max_num_cqs = min_t(int, rblock->max_cq,
+ EHCA_MAX_NUM_QUEUES);
+ else if (shca->max_num_cqs < 1 || shca->max_num_cqs > rblock->max_cq) {
+ ehca_gen_warn("The requested number of CQs is out of range "
+ "(1 - %i) specified by HW. Value is set to %i",
+ rblock->max_cq, rblock->max_cq);
}
/* query max MTU from first port -- it's the same for all ports */
@@ -733,9 +734,13 @@ static int __devinit ehca_probe(struct of_device *dev,
ehca_gen_err("Cannot allocate shca memory.");
return -ENOMEM;
}
+
mutex_init(&shca->modify_mutex);
atomic_set(&shca->num_cqs, 0);
atomic_set(&shca->num_qps, 0);
+ shca->max_num_qps = ehca_max_qp;
+ shca->max_num_cqs = ehca_max_cq;
+
for (i =
Re: powerpc allmodconfig
* David Miller <[EMAIL PROTECTED]> wrote: > > net/dccp/options.c: In function 'dccp_parse_options': > > net/dccp/options.c:67: warning: 'value' may be used uninitialized in > > this function > > Known issue, not trivial to fix, gcc is just being incredibly silly > here as it can't see all of the control flow. i just ran into this - do you have any objection against the patch below? Should we have a cleaner annotation perhaps instead of uninitialized_var()? Something like: #define __used __attribute__((used)) ? Ingo --> From d917af0bd043eab40d57f79cba9cf7a7b265a205 Mon Sep 17 00:00:00 2001 From: Ingo Molnar <[EMAIL PROTECTED]> Date: Fri, 17 Oct 2008 12:41:30 +0200 Subject: [PATCH] fix warning in net/dccp/options.c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit fix this warning: net/dccp/options.c: In function ‘dccp_parse_options’: net/dccp/options.c:67: warning: ‘value’ may be used uninitialized in this function This is a bogus GCC warning. The compiler does not recognize the relation between "value" and "mandatory" variables: the code flow can ever reach the "out_invalid_option:" label if 'mandatory' is set to 1, and when 'mandatory' is non-zero, we'll always have 'value' initialized. Help out the compiler by annotating the variable. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> --- net/dccp/options.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/dccp/options.c b/net/dccp/options.c index 0809b63..18dcfb9 100644 --- a/net/dccp/options.c +++ b/net/dccp/options.c @@ -64,7 +64,7 @@ int dccp_parse_options(struct sock *sk, struct dccp_request_sock *dreq, (dh->dccph_doff * 4); struct dccp_options_received *opt_recv = &dp->dccps_options_received; unsigned char opt, len; - unsigned char *value; + unsigned char *uninitialized_var(value); u32 elapsed_time; __be32 opt_val; int rc; ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Oops in during system run
Hi all, This is a peculiar Oops we are encountering during the running of our board (sh4) architecture we are some times getting Oops messages like this Unable to handle kernel NULL pointer dereference at virtual address 0004 pc = 844240f8 *pde = Oops: 0001 [#1] Pid : 529, Comm: cvm PC is at run_timer_softirq+0x58/0x220 PC : 844240f8 SP : 88d1ff44 SR : 400080f0 TEA : c0169d64Tainted: P R0 : R1 : 88d1ff44 R2 : R3 : 846fa08c R4 : 846fa084 R5 : 846fae8c R6 : 0001 R7 : R8 : R9 : 846fa084 R10 : 84424020 R11 : 88d1ff0c R12 : 88d1ff44 R13 : 846fba08 R14 : ffd3 MACH: 0050 MACL: 0078 GBR : 397b6938 PR : 844241a2 Call trace: [<8442137a>] __do_softirq+0x7a/0x120 [<844218a6>] irq_exit+0x66/0x80 [<84407e80>] do_IRQ+0x0/0x60 [<84407eb8>] do_IRQ+0x38/0x60 [<84405070>] ret_from_irq+0x0/0x10 Kernel panic - not syncing: Aiee, killing interrupt handler! I think this crash is a generic problem in our kernel configuration. can any one help? >From the log, is it possible to tell what may cause these kind of behavior? The same crash is happening at different times during different operations. Please Give you valuable suggestions!! Regards, Sreejith M M Engineer||D&D Tata Elxsi Limited _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ganesh Kumar N M Sent: Thursday, October 16, 2008 6:56 PM To: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED] Cc: Ganesh Kumar NM Subject: Loadable module crashes at kernel stack overflow or machine check Hi All, I'm working on MPC860 with Montavista linux 2.4.18 We have a Linux kernel loadable module which on loading panicks after some random time say 8 hours, 4 hours or so the oops outputs say either machine check exception or kernel stack overflow (randomly both show up) are as below: Machine check in kernel mood/e. Caused by lPC:M C000A934 XER:3REGS: c0b73cb0 TRAP: 0200Tainted: PF MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0b72000[3] 'ksoftirqd_CPU0' Last syscall: -1 last math last altivec GPR00: C0B73D60 C0B72000 000B GPR08: E244E000 C01A 0014 0002 100374B8 1FFFA000 007FFF36 GPR16: 0001 007FFF00 9032 00B73E30 C00029D4 GPR24: 00030001 C0B73E40 000B 0820 C0B73E40 Call backtrace: C00CB774 C0009CBC C00029D4 C0B73FA0 C00E0208 C00E8800 C00D8920 C0014E98 C0015524 C0004D88 Machine check in kernel mode. Caused by (from SRR1=1032): Transfer error ack signal Oops: machine check, sig: 7 NIP: C000A934 XER: LR: C0009EFC SP: C0B73990 REGS: c0b738e0 TRAP: 0200F MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0b72000[3] 'ksoftirqd_CPU0' Last syscall: -1 last math last altivec GPR00: C0B73990 C0B72000 E20286D0 E242D03C 000B C01F6268 E20286D0 GPR08: E244E000 C01A C01B4F1C 0002 24004028 100374B8 1FFFA000 007FFF36 GPR16: 0001 007FFF00 1032 00B73A60 C00029D4 GPR24: 00030001 C0B73A70 E242D03C 000B 8800 C0B73A70 Call backtrace: C0B73A40 C0009CBC C00029D4 E20286D0 C00CB774 C00039EC C0003AB0 C00029CC C0002B54 C0002C74 C00029D4 C00CB774 C0009CBC C00029D4 C0B73FA0 C00E0208 C00E8800 C00D8920 C0014E98 C0015524 C0004D88 Kernel stack overflow in process c018e030, r1=c018e370 NIP: C000A934 XER: LR: C0009EFC SP: C018E370 REGS: c018e2c0 TRAP: 0300Tainted: PF MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: E2474034, DSISR: 8800 TASK = c018e030[0] 'swapper' Last syscall: 120 last math last altivec GPR00: C0009CBC C018E370 C018E030 C000A934 E2474034 000B C0B6C400 C000A934 GPR08: E2474000 C01A 0014 0002 002AE754 10052EC8 1FFFA000 007FFF1C GPR16: 0001 007FFF00 9032 0018E440 C00029D4 GPR24: 00030001 C018E450 E2474034 000B 8800 C018E450 Call backtrace: C0009CBC C00029D4 000B C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 Kernel panic: kernel stack overflow In interrupt handler - not syncing <0>Rebooting in 180 seconds.. === Looking at the Ksymoops pointed me to some do_page_fault ksymoops 2.4.6 on i686 2.4.18-3smp. Options used -V (default) -k ksyms (specified) -L (default) -O (default) -m System.map (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ipt_MASQUERADE .o) for ipt_MASQUERADE Error (expand_obje
Loadable module crashes at kernel stack overflow or machine check
Hi All, I'm working on MPC860 with Montavista linux 2.4.18 We have a Linux kernel loadable module which on loading panicks after some random time say 8 hours, 4 hours or so the oops outputs say either machine check exception or kernel stack overflow (randomly both show up) are as below: Machine check in kernel mood/e. Caused by lPC:M C000A934 XER:3REGS: c0b73cb0 TRAP: 0200Tainted: PF MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0b72000[3] 'ksoftirqd_CPU0' Last syscall: -1 last math last altivec GPR00: C0B73D60 C0B72000 000B GPR08: E244E000 C01A 0014 0002 100374B8 1FFFA000 007FFF36 GPR16: 0001 007FFF00 9032 00B73E30 C00029D4 GPR24: 00030001 C0B73E40 000B 0820 C0B73E40 Call backtrace: C00CB774 C0009CBC C00029D4 C0B73FA0 C00E0208 C00E8800 C00D8920 C0014E98 C0015524 C0004D88 Machine check in kernel mode. Caused by (from SRR1=1032): Transfer error ack signal Oops: machine check, sig: 7 NIP: C000A934 XER: LR: C0009EFC SP: C0B73990 REGS: c0b738e0 TRAP: 0200F MSR: 1032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0b72000[3] 'ksoftirqd_CPU0' Last syscall: -1 last math last altivec GPR00: C0B73990 C0B72000 E20286D0 E242D03C 000B C01F6268 E20286D0 GPR08: E244E000 C01A C01B4F1C 0002 24004028 100374B8 1FFFA000 007FFF36 GPR16: 0001 007FFF00 1032 00B73A60 C00029D4 GPR24: 00030001 C0B73A70 E242D03C 000B 8800 C0B73A70 Call backtrace: C0B73A40 C0009CBC C00029D4 E20286D0 C00CB774 C00039EC C0003AB0 C00029CC C0002B54 C0002C74 C00029D4 C00CB774 C0009CBC C00029D4 C0B73FA0 C00E0208 C00E8800 C00D8920 C0014E98 C0015524 C0004D88 Kernel stack overflow in process c018e030, r1=c018e370 NIP: C000A934 XER: LR: C0009EFC SP: C018E370 REGS: c018e2c0 TRAP: 0300 Tainted: PF MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 DAR: E2474034, DSISR: 8800 TASK = c018e030[0] 'swapper' Last syscall: 120 last math last altivec GPR00: C0009CBC C018E370 C018E030 C000A934 E2474034 000B C0B6C400 C000A934 GPR08: E2474000 C01A 0014 0002 002AE754 10052EC8 1FFFA000 007FFF1C GPR16: 0001 007FFF00 9032 0018E440 C00029D4 GPR24: 00030001 C018E450 E2474034 000B 8800 C018E450 Call backtrace: C0009CBC C00029D4 000B C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 C0009CBC C00029D4 Kernel panic: kernel stack overflow In interrupt handler - not syncing <0>Rebooting in 180 seconds.. === Looking at the Ksymoops pointed me to some do_page_fault ksymoops 2.4.6 on i686 2.4.18-3smp. Options used -V (default) -k ksyms (specified) -L (default) -O (default) -m System.map (specified) Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ipt_MASQUERADE.o) for ipt_MASQUERADE Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/iptable_filter.o) for iptable_filter Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ip_nat_ftp.o) for ip_nat_ftp Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/iptable_nat.o) for iptable_nat Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ip_conntrack_irc.o) for ip_conntrack_irc Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ip_conntrack_ftp.o) for ip_conntrack_ftp Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ip_conntrack.o) for ip_conntrack Error (expand_objects): cannot stat(/lib/modules/2.4.18_mvl30-fads/kernel/net/ipv4/netfilter/ip_tables.o) for ip_tables Error (expand_objects): cannot stat(/home/ICM/ISDN/sig860el.o) for sig860el Error (expand_objects): cannot stat(/home/ICM/LKM/sysk_procif_ver.o) for sysk_procif_ver Warning (compare_maps): mismatch on symbol xchg_u32 , ksyms_base says c00095e4, System.map says c0004af0. Ignoring ksyms_base entry Kernel stack overflow in process c0a08000, r1=c0a08460 NIP: C000A934 XER: LR: C0009EFC SP: C0A08460 REGS: c0a083b0 TRAP: 0300F Using defaults from ksymoops -t elf32-little -a unknown MSR: 9032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK = c0a08000[1] 'init' Last syscall: 106 last math last altivec GPR00: C0A08460 C0A08000 C000A934 E2433034 000B C0B6AA00 C000A934 GPR08: E2
Re: [PATCH] powerpc: enable heap randomization for linkstations
Hi, This other patch was also sent some days ago and I would appreciate some feedback on it. Regards, Rogério Brito. On Oct 13 2008, Rogério Brito wrote: > The current defconfig for Linkstation/Kuroboxes has the "Disable Heap > Randomization" option enabled. > > Since some of these machines are facing the internet, it helps to have > heap randomization enabled. This patch enables it. > > > Signed-off-by: Rogério Brito <[EMAIL PROTECTED]> > > --- > > --- linux/arch/powerpc/configs/linkstation_defconfig.old 2008-10-13 > 00:33:00.0 -0300 > +++ linux/arch/powerpc/configs/linkstation_defconfig 2008-10-13 > 01:11:28.0 -0300 > @@ -1,7 +1,7 @@ > # > # Automatically generated make config: don't edit > -# Linux kernel version: 2.6.27-rc4 > -# Thu Aug 21 00:52:05 2008 > +# Linux kernel version: 2.6.27 > +# Mon Oct 13 01:11:21 2008 > # > # CONFIG_PPC64 is not set > > @@ -101,7 +101,7 @@ CONFIG_HOTPLUG=y > CONFIG_PRINTK=y > CONFIG_BUG=y > CONFIG_ELF_CORE=y > -CONFIG_COMPAT_BRK=y > +# CONFIG_COMPAT_BRK is not set > CONFIG_BASE_FULL=y > CONFIG_FUTEX=y > CONFIG_ANON_INODES=y > @@ -1211,7 +1211,6 @@ CONFIG_USB_STORAGE=m > # CONFIG_USB_STORAGE_ALAUDA is not set > # CONFIG_USB_STORAGE_ONETOUCH is not set > # CONFIG_USB_STORAGE_KARMA is not set > -# CONFIG_USB_STORAGE_SIERRA is not set > # CONFIG_USB_STORAGE_CYPRESS_ATACB is not set > # CONFIG_USB_LIBUSUAL is not set > > > -- > Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 > http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito > Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: compile kernel for linkstations optimized for size
Hi, It's been some days since I sent the patch below. I would appreciate if any feedback was given. Thanks, Rogério Brito. On Oct 13 2008, Rogério Brito wrote: > From: Rogério Brito <[EMAIL PROTECTED]> > > Since Linkstations and Kuroboxes often have *very* little memory (as > they are embedded systems), it is desirable to get their kernels > compiled optimized for size. > > Signed-off-by: Rogério Brito <[EMAIL PROTECTED]> > > --- > > I have been using kernels optimized for size on my Kurobox (standard) > for many different releases and I have experienced no problem with this > option enabled. Thus, this patch. > > --- linux/arch/powerpc/configs/linkstation_defconfig.old 2008-10-13 > 00:33:00.0 -0300 > +++ linux/arch/powerpc/configs/linkstation_defconfig 2008-10-13 > 00:38:58.0 -0300 > @@ -90,7 +90,7 @@ CONFIG_NAMESPACES=y > # CONFIG_PID_NS is not set > CONFIG_BLK_DEV_INITRD=y > CONFIG_INITRAMFS_SOURCE="" > -# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set > +CONFIG_CC_OPTIMIZE_FOR_SIZE=y > CONFIG_SYSCTL=y > # CONFIG_EMBEDDED is not set > CONFIG_SYSCTL_SYSCALL=y > > > -- > Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 > http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito > Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 2/7] i2c: add info->archdata field
Hi Anton,
On Thu, 16 Oct 2008 21:12:53 +0400, Anton Vorontsov wrote:
> If present the info->archdata is copied into the dev->archdata.
> Some (OpenFirmware) platforms need it.
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> drivers/i2c/i2c-core.c |3 +++
> include/linux/i2c.h|2 ++
> 2 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> index 42e852d..5a485c2 100644
> --- a/drivers/i2c/i2c-core.c
> +++ b/drivers/i2c/i2c-core.c
> @@ -266,6 +266,9 @@ i2c_new_device(struct i2c_adapter *adap, struct
> i2c_board_info const *info)
>
> client->dev.platform_data = info->platform_data;
>
> + if (info->archdata)
> + client->dev.archdata = *info->archdata;
> +
> client->flags = info->flags;
> client->addr = info->addr;
> client->irq = info->irq;
> diff --git a/include/linux/i2c.h b/include/linux/i2c.h
> index 0611512..3e358d3 100644
> --- a/include/linux/i2c.h
> +++ b/include/linux/i2c.h
> @@ -240,6 +240,7 @@ static inline void i2c_set_clientdata (struct i2c_client
> *dev, void *data)
> * @flags: to initialize i2c_client.flags
> * @addr: stored in i2c_client.addr
> * @platform_data: stored in i2c_client.dev.platform_data
> + * @archdata: copied into i2c_client.dev.archdata
> * @irq: stored in i2c_client.irq
> *
> * I2C doesn't actually support hardware probing, although controllers and
> @@ -259,6 +260,7 @@ struct i2c_board_info {
> unsigned short flags;
> unsigned short addr;
> void*platform_data;
> + struct dev_archdata *archdata;
> int irq;
> };
>
No objection from me:
Acked-by: Jean Delvare <[EMAIL PROTECTED]>
Let me know if I should push this patch upstream myself.
--
Jean Delvare
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [RESEND] i2c-cpm: Suppress autoprobing for devices
Hi Wolfram, On Thu, 16 Oct 2008 21:12:00 +0200, Wolfram Sang wrote: > Similar to commit 618b26d52843c0f85b8eb143cf2695d7f6fd072d, also remove > automatic probing for this i2c controller. Might need updates to dts files > using it. > > Signed-off-by: Wolfram Sang <[EMAIL PROTECTED]> > Acked-by: Jochen Friedrich <[EMAIL PROTECTED]> > --- > Resend with cc to i2c. > > drivers/i2c/busses/i2c-cpm.c |1 - > 1 file changed, 1 deletion(-) > > Index: linux-2.6/drivers/i2c/busses/i2c-cpm.c > === > --- linux-2.6.orig/drivers/i2c/busses/i2c-cpm.c > +++ linux-2.6/drivers/i2c/busses/i2c-cpm.c > @@ -423,7 +423,6 @@ static const struct i2c_adapter cpm_ops > .owner = THIS_MODULE, > .name = "i2c-cpm", > .algo = &cpm_i2c_algo, > - .class = I2C_CLASS_HWMON | I2C_CLASS_SPD, > }; > > static int __devinit cpm_i2c_setup(struct cpm_i2c *cpm) Acked-by: Jean Delvare <[EMAIL PROTECTED]> I guess you do _not_ want me to push this patch upstream now and it better goes through the powerpc tree to allow a synchronization with dts file changes? If I'm wrong and you want me to take this patch in my tree then please tell me. -- Jean Delvare ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Problems with PCI-E devices not being detected with switch
On Friday 17 October 2008, Benjamin Herrenschmidt wrote: > Ok, can you send me a full dmesg log with "debug" on the kernel command > line after adding a #define DEBUG 1 to the top of drivers/pci/probe.c > please ? (before the batch of #include). > > The generic code is _supposed_ to somewhat figure out that bridges > haven't been setup by the firmware and fix that up, but for some reason > it's not happening I think. Or something else is wrong ... > > Stefan, I could use the same log from your customer too. OK. I'll try to provide those logs quickly. Best regards, Stefan ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
