[PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
[PATCH v2 1/2] 82xx, mgcoge: updates for 2.6.32
- add I2C support
- add FCC1 and FCC2 support
- fix bogus gpio numbering in plattformcode
Signed-off-by: Heiko Schocher h...@denx.de
---
- against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git
next branch
- checked with checkpatch.pl:
$ ./scripts/checkpatch.pl 0001-82xx-mgcoge-updates-for-2.6.32.patch
total: 0 errors, 0 warnings, 147 lines checked
0001-82xx-mgcoge-updates-for-2.6.32.patch has no obvious style problems and is
ready for submission.
$
- changes since v1
- Add comments from David Gibson
removed 2 device_type entries
- Add comment from Kumar Gala
splittet into 2 patches (seperated defconfig patch)
arch/powerpc/boot/dts/mgcoge.dts | 53 ++
arch/powerpc/platforms/82xx/mgcoge.c | 69 +
2 files changed, 113 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/boot/dts/mgcoge.dts b/arch/powerpc/boot/dts/mgcoge.dts
index 633255a..0ce9664 100644
--- a/arch/powerpc/boot/dts/mgcoge.dts
+++ b/arch/powerpc/boot/dts/mgcoge.dts
@@ -162,6 +162,59 @@
fixed-link = 0 0 10 0 0;
};
+ i...@11860 {
+ compatible = fsl,mpc8272-i2c,
+fsl,cpm2-i2c;
+ reg = 0x11860 0x20 0x8afc 0x2;
+ interrupts = 1 8;
+ interrupt-parent = PIC;
+ fsl,cpm-command = 0x2960;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
+
+ m...@10d40 {
+ compatible = fsl,cpm2-mdio-bitbang;
+ reg = 0x10d00 0x14;
+ #address-cells = 1;
+ #size-cells = 0;
+ fsl,mdio-pin = 12;
+ fsl,mdc-pin = 13;
+
+ phy0: ethernet-...@0 {
+ reg = 0x0;
+ };
+
+ phy1: ethernet-...@1 {
+ reg = 0x1;
+ };
+ };
+
+ /* FCC1 management to switch */
+ ether...@11300 {
+ device_type = network;
+ compatible = fsl,cpm2-fcc-enet;
+ reg = 0x11300 0x20 0x8400 0x100 0x11390 0x1;
+ local-mac-address = [ 00 01 02 03 04 07 ];
+ interrupts = 32 8;
+ interrupt-parent = PIC;
+ phy-handle = phy0;
+ linux,network-index = 1;
+ fsl,cpm-command = 0x12000300;
+ };
+
+ /* FCC2 to redundant core unit over backplane */
+ ether...@11320 {
+ device_type = network;
+ compatible = fsl,cpm2-fcc-enet;
+ reg = 0x11320 0x20 0x8500 0x100 0x113b0 0x1;
+ local-mac-address = [ 00 01 02 03 04 08 ];
+ interrupts = 33 8;
+ interrupt-parent = PIC;
+ phy-handle = phy1;
+ linux,network-index = 2;
+ fsl,cpm-command = 0x16200300;
+ };
};
PIC: interrupt-control...@10c00 {
diff --git a/arch/powerpc/platforms/82xx/mgcoge.c
b/arch/powerpc/platforms/82xx/mgcoge.c
index c2af169..7a5de9e 100644
--- a/arch/powerpc/platforms/82xx/mgcoge.c
+++ b/arch/powerpc/platforms/82xx/mgcoge.c
@@ -50,16 +50,63 @@ struct cpm_pin {
static __initdata struct cpm_pin mgcoge_pins[] = {
/* SMC2 */
- {1, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {1, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {0, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {0, 9, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
/* SCC4 */
- {3, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {3, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
- {4, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+ {2, 25, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 24, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 9, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {2, 8, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
+ {3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
+
+ /* FCC1 */
+ {0, 14,
[PATCH v2 2/2] 82xx, mgcoge: update defconfig for 2.6.32
- add I2C support - add FCC1 and FCC2 support Signed-off-by: Heiko Schocher h...@denx.de --- - against git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git next branch - checked with checkpatch.pl: $ ./scripts/checkpatch.pl 0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch total: 0 errors, 0 warnings, 381 lines checked 0002-82xx-mgcoge-update-defconfig-for-2.6.32.patch has no obvious style problems and is ready for submission. $ - changes since v1 - Add comments from David Gibson removed 2 device_type entries - Add comment from Kumar Gala splittet into 2 patches (seperated defconfig patch) arch/powerpc/configs/mgcoge_defconfig | 178 +--- 1 files changed, 139 insertions(+), 39 deletions(-) diff --git a/arch/powerpc/configs/mgcoge_defconfig b/arch/powerpc/configs/mgcoge_defconfig index 31e1df6..a6fe6b0 100644 --- a/arch/powerpc/configs/mgcoge_defconfig +++ b/arch/powerpc/configs/mgcoge_defconfig @@ -1,25 +1,27 @@ # # Automatically generated make config: don't edit -# Linux kernel version: 2.6.30-rc3 -# Wed May 13 17:21:55 2009 +# Linux kernel version: 2.6.31-rc4 +# Wed Jul 29 08:57:10 2009 # # CONFIG_PPC64 is not set # # Processor support # -CONFIG_6xx=y +CONFIG_PPC_BOOK3S_32=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_BOOK3S=y +CONFIG_6xx=y CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set +CONFIG_PPC_HAVE_PMU_SUPPORT=y # CONFIG_SMP is not set CONFIG_PPC32=y CONFIG_WORD_SIZE=32 @@ -30,15 +32,16 @@ CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y -CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_GPIO=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set @@ -53,6 +56,7 @@ CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y +CONFIG_DTC=y # CONFIG_DEFAULT_UIMAGE is not set CONFIG_HIBERNATE_32=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y @@ -60,6 +64,7 @@ CONFIG_ARCH_HIBERNATION_POSSIBLE=y # CONFIG_PPC_DCR_MMIO is not set CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config +CONFIG_CONSTRUCTORS=y # # General setup @@ -105,7 +110,6 @@ CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set -# CONFIG_STRIP_ASM_SYMS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y @@ -119,8 +123,15 @@ CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y +CONFIG_HAVE_PERF_COUNTERS=y + +# +# Performance Counters +# +# CONFIG_PERF_COUNTERS is not set CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y +# CONFIG_STRIP_ASM_SYMS is not set CONFIG_COMPAT_BRK=y CONFIG_SLAB=y # CONFIG_SLUB is not set @@ -134,6 +145,11 @@ CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_CLK=y + +# +# GCOV-based kernel profiling +# +# CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y @@ -141,7 +157,7 @@ CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_BLOCK=y -# CONFIG_LBD is not set +CONFIG_LBDAF=y # CONFIG_BLK_DEV_INTEGRITY is not set # @@ -225,6 +241,7 @@ CONFIG_BINFMT_ELF=y # CONFIG_HAVE_AOUT is not set CONFIG_BINFMT_MISC=y # CONFIG_IOMMU_HELPER is not set +# CONFIG_SWIOTLB is not set CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y CONFIG_ARCH_HAS_WALK_MEMORY=y CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y @@ -240,9 +257,9 @@ CONFIG_MIGRATION=y CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_VIRT_TO_BUS=y -CONFIG_UNEVICTABLE_LRU=y CONFIG_HAVE_MLOCK=y CONFIG_HAVE_MLOCKED_PAGE_BIT=y +CONFIG_DEFAULT_MMAP_MIN_ADDR=4096 CONFIG_PPC_4K_PAGES=y # CONFIG_PPC_16K_PAGES is not set # CONFIG_PPC_64K_PAGES is not set @@ -313,6 +330,7 @@ CONFIG_IP_PNP_BOOTP=y # CONFIG_NET_IPIP is not set # CONFIG_NET_IPGRE is not set # CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set @@ -374,7 +392,11 @@ CONFIG_WIRELESS=y CONFIG_WIRELESS_OLD_REGULATORY=y # CONFIG_WIRELESS_EXT is not set # CONFIG_LIB80211 is not set -# CONFIG_MAC80211 is not set + +# +# CFG80211 needs to be enabled for MAC80211 +# +CONFIG_MAC80211_DEFAULT_PS_VALUE=0 # CONFIG_WIMAX is not set # CONFIG_RFKILL is not set @@ -484,6 +506,8 @@ CONFIG_MTD_PHYSMAP_OF=y # CONFIG_MTD_UBI is not set CONFIG_OF_DEVICE=y CONFIG_OF_GPIO=y +CONFIG_OF_I2C=y +CONFIG_OF_MDIO=y #
Re: [FTRACE] Enabling function_graph causes OOPS
Steven Rostedt wrote: Thanks, I've seen issues with my PPC box and function graph, but the bugs were also caused by other changes. I'll boot up my PPC64 box and see if I see the same issues you have. Hi Steven, I can still recreate this issue with 2.6.31-rc5. Let me know if i can provide any information to find a solution for this. Thanks -Sachin -- - Sachin Sant IBM Linux Technology Center India Systems and Technology Labs Bangalore, India - ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Read buffer overflow
Check whether index is within bounds before grabbing the element.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/macintosh/macio_asic.c b/drivers/macintosh/macio_asic.c
index a0f6838..588a5b0 100644
--- a/drivers/macintosh/macio_asic.c
+++ b/drivers/macintosh/macio_asic.c
@@ -294,10 +294,11 @@ static void macio_setup_interrupts(struct macio_dev *dev)
int i = 0, j = 0;
for (;;) {
- struct resource *res = dev-interrupt[j];
+ struct resource *res;
if (j = MACIO_DEV_COUNT_IRQS)
break;
+ res = dev-interrupt[j];
irq = irq_of_parse_and_map(np, i++);
if (irq == NO_IRQ)
break;
@@ -321,9 +322,10 @@ static void macio_setup_resources(struct macio_dev *dev,
int index;
for (index = 0; of_address_to_resource(np, index, r) == 0; index++) {
- struct resource *res = dev-resource[index];
+ struct resource *res;
if (index = MACIO_DEV_COUNT_RESOURCES)
break;
+ res = dev-resource[index];
*res = r;
res-name = dev_name(dev-ofdev.dev);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Read buffer overflow
Roel Kluin writes: Check whether index is within bounds before grabbing the element. The change seems unnecessary since we only compute the address of the element before the bounds check, we don't actually access the element. I believe that is legal in C. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Kernel fault with simple UIO interrupt driver in 2.6.30.4
Hi all,
due to a new revision of our custimized board, i need to port our current
kernel (2.6.24)
to the latest kernel version 2.6.30.4.
Among other things the UIO interrupt driver makes some trouble. The driver runs
smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4.
It's a very simple interrupt driver which will be register for a certain
external
cpu interrupt and informs our application via /dev/uioX when an interrupt
occurs.
Is there anything that changed in the uio framework that could cause the
kernel fault with our uio driver?
Our driver looks like follow
-
#include linux/uio_driver.h
#include linux/platform_device.h
#include linux/module.h
static irqreturn_t interrupt_handler_irq4(int irq, struct uio_info *dev_info)
{
return IRQ_HANDLED;
}
static struct uio_info uio_irq4_info = {
.name = IRQ4 Kernel Driver,
.version = 1.0.1,
.irq = 20,
.irq_flags =IRQF_DISABLED | IRQF_SHARED | IRQF_TRIGGER_FALLING,
.handler= interrupt_handler_irq4,
};
static int uio_irq4_probe(struct device *dev)
{
if (uio_register_device(dev, uio_irq4_info)) {
kfree((void *)uio_irq4_info.mem[0].addr);
return -ENODEV;
}
else
{
return 0;
}
}
static int uio_irq4_remove(struct device *dev)
{
uio_unregister_device(uio_irq4_info);
return 0;
}
static void uio_irq4_shutdown(struct device *dev)
{
}
static struct platform_device *uio_irq4_device;
static struct device_driver uio_irq4_driver = {
.name = IRQ4,
.bus= platform_bus_type,
.probe = uio_irq4_probe,
.remove = uio_irq4_remove,
.shutdown = uio_irq4_shutdown,
};
/*
* Main initialization/remove routines
*/
static int __init uio_irq4_init(void)
{
uio_irq4_device = platform_device_register_simple(IRQ4, -1,
NULL, 0);
if (IS_ERR(uio_irq4_device))
return PTR_ERR(uio_irq4_device);
return driver_register(uio_irq4_driver);
}
static void __exit uio_irq4_exit(void)
{
platform_device_unregister(uio_irq4_device);
driver_unregister(uio_irq4_driver);
}
module_init(uio_irq4_init);
module_exit(uio_irq4_exit);
MODULE_LICENSE(tbd);
MODULE_AUTHOR(Frank Prepelica, Ubidyne GmbH);
MODULE_DESCRIPTION(IRQ4 Interrupt Handler - CPLD Interrupts);
-
Any help is highly appreciated!
Kind Regards
Frank Prepelica
Software Design Engineer
Ubidyne GmbH
Lise-Meitner-Str.-14
89081 Ulm - Germany
Phone: +49 731 88 00 71 58
Fax: +49 731 88 00 71 99
Email: frank.prepel...@ubidyne.com
Homepage: www.ubidyne.com
Registered office: Ulm
District court of Ulm: HRB 5295
Managing Directors:
Dipl. Ing. Ken Hawk
Dipl. Ing. Beat Müller
Dipl. Ing. Mike Levis
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: Read buffer overflow
On Mon, Aug 03, 2009 at 10:57:17PM +1000, Paul Mackerras wrote: Roel Kluin writes: Check whether index is within bounds before grabbing the element. The change seems unnecessary since we only compute the address of the element before the bounds check, we don't actually access the element. I believe that is legal in C. I've got this strange feeling of deja vu :) http://thread.gmane.org/gmane.linux.ports.arm.kernel/63507 (I'd vote for applying it but won't mind if not) Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
On Sun, 2009-08-02 at 17:50 +1000, Benjamin Herrenschmidt wrote:
On Sat, 2009-08-01 at 10:00 +0100, David Woodhouse wrote:
I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
doesn't seem ideal, and we'll want to make the no-iommu code DTRT
_anyway_, surely?
So we might as well let the DART keep its existing logic (which is
only
to bother if we have more than 1GiB of RAM;
Ah right, so when do we enable the DART ? Above 1G ? I though it was
above 2G but we may well have moved that down to 1G just for b43 indeed.
void __init alloc_dart_table(void)
{
/* Only reserve DART space if machine has more than 1GB of RAM
* or if requested with iommu=on on cmdline.
*
* 1GB of RAM is picked as limit because some default devices
* (i.e. Airport Extreme) have 30 bit address range limits.
*/
if (iommu_is_off)
return;
if (!iommu_force_on lmb_end_of_DRAM() = 0x4000ull)
return;
I definitely agree on the fix to the mask so it only compares to the
available RAM. I'll check that in when I'm back from the snow fields
on tuesday :-)
I see one potential failure mode with this. You need:
- No IOMMU
- Crappy devices
- Hotpluggable memory
- Boot with only low memory, and allow a pci_set_dma_mask() to
succeed because you don't have that much memory anyway.
- Hotplug some high memory that the crappy device can't reach.
Do we care about that scenario? I think we might be able to fix it by
setting the memory_limit when we allow pci_set_dma_mask() to succeed?
That will effectively prevent the addition of memory that our crappy
device can't reach, won't it?
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
Hi, On Fri, 2009-07-31 at 16:10 +1000, David Gibson wrote: On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote: Hi David, I'm back with a new version of patches after a brief hiatus! After much deliberation about modifying the code to change the timing of signal delivery to user-space, it has been decided to retain the existing behaviour i.e. SIGTRAP delivered to user-space after execution of causative instruction although exception is raised before execution of it. Ok. Except, presumably for ptrace, since changing that would break gdb. Yes. GDB works with some assumptions in mind. Hardware breakpoints (they're not supported right now) trigger before execution, then GDB just removes them and stepi's until we're past the breakpoint. As for HW watchpoints, we always stop before execution (by ppc design presumably). GDB will check the value before the trigger, remove the HW watch, stepi it, and will check the value again to see if it has changed. If we're to trigger after the data load/store has happened, we could have breakage in GDB. Regards, Luis ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
/* XXX This clear should ultimately be part of
local_flush_tlb_mm */
- __clear_bit(id, stale_map[cpu]);
+ for (cpu = cpu_first_thread_in_core(cpu);
+ cpu = cpu_last_thread_in_core(cpu); cpu++)
+ __clear_bit(id, stale_map[cpu]);
}
This looks a bit dodgy. using 'cpu' as both the loop variable and
what you are computing to determine loop start/end..
Hrm... I would have thought that it was still correct... do you see
any
reason why the above code is wrong ? because if not we may be
hitting a
gcc issue...
IE. At loop init, cpu gets clamped down to the first thread in the
core,
which should be fine. Then, we compare CPU to the last thread in core
for the current CPU which should always return the same value.
So I'm very interested to know what is actually wrong, ie, either I'm
just missing something obvious, or you are just pushing a bug under
the
carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu = cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu = cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu = 1
cpu++ (1)
cpu = 1
cpu++ (2)
cpu = 3
...
Which is pretty much what I see, in a dual core setup, I get an oops
because we are trying to clear cpu #2 (which clearly doesn't exist)
cpu = 1
(in loop)
clearing 1
clearing 2
OOPS
- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
In the current code, all MPC5200 timers are registered by the
mpc52xx_gpt driver, even if gpt0 (the only one with this capability)
shall be used as hardware watchdog which is indicated by the
fsl,has-wdt or has-wdt property in the device tree. Thus, the
watchdog driver does never find any watchdog and simply doesn't work.
This trivial patch protects timers with a (fsl,)?has-wdt property
from being probed as gpt's. The watchdog timer now works just fine.
Tested on a custom (roughly Icecube based) MPC5200B board, with the
5200 watchdog driver built into the kernel.
Signed-off-by: Albrecht Dreß albrecht.dr...@arcor.de
---
--- linux-2.6.30.3.orig/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
2009-07-24 23:47:51.0 +0200
+++ linux-2.6.30.3/arch/powerpc/platforms/52xx/mpc52xx_gpt.c
2009-08-03 14:20:10.0 +0200
@@ -343,6 +343,14 @@
{
struct mpc52xx_gpt_priv *gpt;
+ /* do not grab devices which shall be used as watchdog */
+ if (of_get_property(ofdev-node, fsl,has-wdt, NULL) ||
+ of_get_property(ofdev-node, has-wdt, NULL)) {
+ pr_notice(%s: ignore wdt %s\n, __func__,
+ ofdev-node-full_name);
+ return -ENODEV;
+ }
+
gpt = kzalloc(sizeof *gpt, GFP_KERNEL);
if (!gpt)
return -ENOMEM;
pgpe9HqkyMwKg.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
On Sat, 2009-08-01 at 08:29 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2009-07-30 at 22:35 -0500, Kumar Gala wrote:
/* XXX This clear should ultimately be part of
local_flush_tlb_mm */
- __clear_bit(id, stale_map[cpu]);
+ for (cpu = cpu_first_thread_in_core(cpu);
+ cpu = cpu_last_thread_in_core(cpu); cpu++)
+ __clear_bit(id, stale_map[cpu]);
}
This looks a bit dodgy. using 'cpu' as both the loop variable and
what you are computing to determine loop start/end..
Hrm... I would have thought that it was still correct... do you see
any
reason why the above code is wrong ? because if not we may be
hitting a
gcc issue...
IE. At loop init, cpu gets clamped down to the first thread in the
core,
which should be fine. Then, we compare CPU to the last thread in core
for the current CPU which should always return the same value.
So I'm very interested to know what is actually wrong, ie, either I'm
just missing something obvious, or you are just pushing a bug under
the
carpet which could come back and bit us later :-)
for (cpu = cpu_first_thread_in_core(cpu);
cpu = cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu = cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu_last_thread_in_core(cpu) is a moving target. You want something
like:
cpu = cpu_first_thread_in_core(cpu);
last = cpu_last_thread_in_core(cpu);
while (cpu = last) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu = 1
cpu++ (1)
cpu = 1
cpu++ (2)
cpu = 3
...
Which is pretty much what I see, in a dual core setup, I get an oops
because we are trying to clear cpu #2 (which clearly doesn't exist)
cpu = 1
(in loop)
clearing 1
clearing 2
OOPS
- k
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
On Mon, 2009-08-03 at 12:06 -0500, Dave Kleikamp wrote:
On Mon, 2009-08-03 at 11:21 -0500, Kumar Gala wrote:
On Aug 2, 2009, at 9:03 PM, Michael Ellerman wrote:
for (cpu = cpu_first_thread_in_core(cpu);
cpu = cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu = cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu_last_thread_in_core(cpu) is a moving target. You want something
like:
cpu = cpu_first_thread_in_core(cpu);
last = cpu_last_thread_in_core(cpu);
while (cpu = last) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
Or, keeping the for loop:
for (cpu = cpu_first_thread_in_core(cpu), last =
cpu_last_thread_in_core(cpu);
cpu = last; cpu++)
cpu++;
cpu = 0
cpu = 1
cpu++ (1)
cpu = 1
cpu++ (2)
cpu = 3
...
Which is pretty much what I see, in a dual core setup, I get an oops
because we are trying to clear cpu #2 (which clearly doesn't exist)
cpu = 1
(in loop)
clearing 1
clearing 2
OOPS
- k
--
David Kleikamp
IBM Linux Technology Center
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
On Mon, Aug 3, 2009 at 10:40 AM, Albrecht Dreßalbrecht.dr...@arcor.de wrote: In the current code, all MPC5200 timers are registered by the mpc52xx_gpt driver, even if gpt0 (the only one with this capability) shall be used as hardware watchdog which is indicated by the fsl,has-wdt or has-wdt property in the device tree. Thus, the watchdog driver does never find any watchdog and simply doesn't work. This trivial patch protects timers with a (fsl,)?has-wdt property from being probed as gpt's. The watchdog timer now works just fine. Blech. This does solve one problem, but it causes another. Just about all mpc5200 device trees have the fsl,has-wdt property on GPT0 even when it isn't used as a watchdog. The boards using GPT0 as a GPIO or timer will be broken by this patch. I know it is a lot more work, but the correct solution is to merge the GPT watchdog driver into the regular GPT driver so that we don't have two device drivers trying to bind against the same device. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/mpc52xx/wdt: Fix 5200 wdt always being used as gpt
Am 03.08.09 19:50 schrieb(en) Grant Likely: Just about all mpc5200 device trees have the fsl,has-wdt property on GPT0 even when it isn't used as a watchdog. Sorry, I do not understand... The file Documentation/powerpc/dts-bindings/fsl/mpc5200.txt says snip On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board design supports the internal wdt, then the device node for GPT0 should include the empty property 'fsl,has-wdt'. /snip I interpreted this as if you don't want to have the wdt function of gpt0, remove this property. If this assumption is wrong, how is the kernel supposed to decide if a device shall be used as gpt or as wdt? The boards using GPT0 as a GPIO or timer will be broken by this patch. A wdt is a security device which will (IMHO) either not be used as such, or it is a *must not* be used for something else on a particular board (you may even want u-boot to activate it, e.g. to detect a hanging boot process). In both cases, a tuned device tree is needed. I know it is a lot more work, but the correct solution is to merge the GPT watchdog driver into the regular GPT driver so that we don't have two device drivers trying to bind against the same device. I see the benefit of removing some duplicate code and of having gpio access in parallel with the wdt, but it wouldn't solve the general confusion above! Will look into that, though... Best, Albrecht. pgpcGH5BRaljs.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
G4 radeon 9500 KMS issues
Hello, I'm testing KMS on my G4 machine, but it is making problems. I tried different approaches: When booting with KMS and agpmode=1 i get this output: [drm] Initialized drm 1.1.0 20060810 [drm] radeon kernel modesetting enabled. [drm:drm_init], [drm:drm_get_dev], radeon :00:10.0: enabling device (0006 - 0007) [drm:drm_get_minor], [drm:drm_get_minor], new minor assigned 64 [drm:drm_get_minor], [drm:drm_get_minor], new minor assigned 0 [drm] radeon: Initializing kernel modesetting. [drm] register mmio base: 0x9000 [drm] register mmio size: 65536 radeon :00:10.0: Invalid ROM contents radeon :00:10.0: Invalid ROM contents [drm:radeon_get_bios] *ERROR* Unable to locate a BIOS ROM [drm] GPU reset succeed (RBBM_STATUS=0x0140) [drm] Using generic clock info [drm] Clocks initialized ! [drm] Generation 2 PCI interface, using max accessible memory [drm] Detected VRAM RAM=32M, BAR=128M [drm] RAM width 64bits DDR [drm] radeon: 1 pipes initialized. agpgart-uninorth :00:0b.0: putting AGP V2 device into 4x mode radeon :00:10.0: putting AGP V2 device into 4x mode [drm] radeon: VRAM 32M [drm] radeon: VRAM from 0x0400 to 0x07FF [drm] radeon: VRAM less than aperture workaround enabled [drm] radeon: GTT 32M [drm] radeon: GTT from 0x to 0x01FF [drm:drm_irq_install], irq=48 [drm] radeon: irq initialized. [TTM] TTM available graphics memory: 757 MiB [TTM] TTM available object memory: 373 MiB [drm] radeon: 32M of VRAM memory ready [drm] radeon: 32M of GTT memory ready. [drm] radeon: cp idle (0x1C03) [drm] Loading R300 Microcode [drm] radeon: ring at 0x [drm] ring test succeeded in 1 usecs [drm] radeon: ib pool ready. [drm:radeon_fence_wait] *ERROR* fence(efb3fea0:0x0001) 510ms timeout going to reset GPU [drm] CP reset succeed (RBBM_STATUS=0x0140) [drm] radeon: cp idle (0x1000) [drm] Loading R300 Microcode [drm] radeon: ring at 0x [drm:radeon_ring_test] *ERROR* radeon: ring test failed (sracth(0x15E8)=0xCAFEDEAD) [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22). [drm:r300_gpu_reset] *ERROR* Failed to reset GPU (RBBM_STATUS=0x80010140) [drm:radeon_fence_wait] *ERROR* fence(efb3fea0:0x0001) 666ms timeout [drm:radeon_fence_wait] *ERROR* last signaled fence(0x0001) [drm:radeon_ib_test] *ERROR* radeon: ib test failed (sracth(0x15E4)=0xCAFEDEAD) [drm:radeon_device_init] *ERROR* radeon: failled testing IB (-22). [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL [drm] radeon: finishing device. [drm] radeon: cp finalized [TTM] Used total memory is 0 bytes. [drm] radeon: ttm finalized [drm:drm_irq_uninstall], irq=48 [drm] radeon: fence finalized [drm:drm_put_minor], release secondary minor 0 [drm:drm_put_minor], release secondary minor 64 radeon: probe of :00:10.0 failed with error -22 When I try to disable AGP, the machine crashes badly. The problem is that I can hardly get any debug output, as the console is not working (see above) and I have to use a SSH session to get any access at all. Here is the log i get: radeon agpmode=-1 Aug 3 13:17:08 [kernel] [drm] radeon kernel modesetting enabled. Aug 3 13:17:08 [kernel] [drm:drm_init], Aug 3 13:17:08 [kernel] [drm:drm_get_dev], Aug 3 13:17:08 [kernel] [drm:drm_get_minor], Aug 3 13:17:08 [kernel] [drm:drm_get_minor], new minor assigned 64 Aug 3 13:17:08 [kernel] [drm:drm_get_minor], Aug 3 13:17:08
Re: [PATCH] powerpc: Read buffer overflow
The change seems unnecessary since we only compute the address of the element before the bounds check, we don't actually access the element. I believe that is legal in C. If you have an array a[N], taking a[0] .. a[N] are legal C, everything else is not. Segher ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 0/6] [Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver VIII
On Fri, Jul 31, 2009 at 04:10:13PM +1000, David Gibson wrote: On Mon, Jul 27, 2009 at 05:41:52AM +0530, K.Prasad wrote: edited Reasons - Signal delivery before execution of instruction requires complex workarounds - One of the plausible workarounds is a two-pass hw-breakpoint handler which delivers the signal after the first pass (with the breakpoints enabled). In the second pass, it follows the existing semantics of disable_hbp--enable_ss--single_step--disable_ss--enable_hbp. Yes, that's the only way I can see to do it. - Possibility of nested exceptions is a problem here. Ok, why? Reason as described in the para below. - Proper identification of a second-pass of first exception and a new nested exception is difficult. Possibility of stray exceptions due to accesses in neighbouring memory regions of the breakpoint address further complicates it. To elaborate, consider a case where a user-space address 'x' is monitored for read or write, and the following happens (assume the existence of the two-pass method for signal delivery). - Instruction 'i' attempts to read/write in address 'x' - hw-bkpt exception generated (pass I) - Signal generated and hw-bkpt exception returns to user-space - Signal is handled before 'i' is executed. Handler code reads/writes data in 'x' again. Generates nested exception. - hw-breakpoint handler code is unable to distinguish if the new exception is from signal handler (nested) or due to second-pass (as per design above). Thanks, K.Prasad ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
On Fri, Jul 31, 2009 at 04:16:46PM +1000, David Gibson wrote:
On Mon, Jul 27, 2009 at 05:43:17AM +0530, K.Prasad wrote:
Introduce PPC64 implementation for the generic hardware breakpoint
interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and
the
Makefile.
[snip]
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ int rc = NOTIFY_STOP;
+ struct hw_breakpoint *bp;
+ struct pt_regs *regs = args-regs;
+ unsigned long dar = regs-dar;
+ int cpu, is_kernel, stepped = 1;
+
+ is_kernel = (hbp_kernel_pos == HBP_NUM) ? 0 : 1;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+
+ cpu = get_cpu();
+ /* Determine whether kernel- or user-space address is the trigger */
+ bp = is_kernel ?
+ per_cpu(this_hbp_kernel[0], cpu) : current-thread.hbp[0];
+ /*
+* bp can be NULL due to lazy debug register switching
+* or due to the delay between updates of hbp_kernel_pos
+* and this_hbp_kernel.
+*/
+ if (!bp)
+ goto out;
+
+ per_cpu(dabr_data, cpu) = is_kernel ? kdabr : current-thread.dabr;
+
+ /* Verify if dar lies within the address range occupied by the symbol
+* being watched. Since we cannot get the symbol size for
+* user-space requests we skip this check in that case
+*/
+ if (is_kernel
+ !((bp-info.address = dar)
+(dar = (bp-info.address + bp-info.symbolsize
+ /*
+* This exception is triggered not because of a memory access on
+* the monitored variable but in the double-word address range
+* in which it is contained. We will consume this exception,
+* considering it as 'noise'.
+*/
+ goto out;
+
+ (bp-triggered)(bp, regs);
It bothers me that the trigger function is executed before the
trapping instruction, but the SIGTRAP occurs afterwards. Since
they're both responses to the trap, it seems logical to me that they
should occur at the same time (from the trapping program's point of
view, at least).
How about moving the triggered function to the single-step handler code
for both kernel- and user-space?
That would make it behave like a trigger-after-execute (and synchronised
with the signal-delivery timing).
+ /*
+* Return early without restoring DABR if the breakpoint is from
+* user-space which always operates in one-shot mode
+*/
+ if (!is_kernel) {
+ rc = NOTIFY_DONE;
+ goto out;
+ }
+
+ stepped = emulate_step(regs, regs-nip);
+ /*
+* Single-step the causative instruction manually if
+* emulate_step() could not execute it
+*/
+ if (stepped == 0) {
+ regs-msr |= MSR_SE;
+ goto out;
+ }
+ set_dabr(per_cpu(dabr_data, cpu));
+
+out:
+ /* Enable pre-emption only if single-stepping is finished */
+ if (stepped) {
+ per_cpu(dabr_data, cpu) = 0;
+ put_cpu();
+ }
+ return rc;
+}
+
+/*
+ * Handle single-step exceptions following a DABR hit.
+ */
+int __kprobes single_step_dabr_instruction(struct die_args *args)
+{
+ struct pt_regs *regs = args-regs;
+ int cpu = get_cpu();
+ int ret = NOTIFY_DONE;
+ siginfo_t info;
+ unsigned long this_dabr_data = per_cpu(dabr_data, cpu);
+
+ /*
+* Check if we are single-stepping as a result of a
+* previous HW Breakpoint exception
+*/
+ if (this_dabr_data == 0)
+ goto out;
+
+ regs-msr = ~MSR_SE;
+ /* Deliver signal to user-space */
+ if (this_dabr_data TASK_SIZE) {
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)(per_cpu(dabr_data, cpu));
+ force_sig_info(SIGTRAP, info, current);
+ }
+
+ set_dabr(this_dabr_data);
+ per_cpu(dabr_data, cpu) = 0;
+ ret = NOTIFY_STOP;
+ /*
+* If single-stepped after hw_breakpoint_handler(), pre-emption is
+* already disabled.
+*/
+ put_cpu();
+
+out:
+ /*
+* A put_cpu() call is required to complement the get_cpu()
+* call used initially
+*/
+ put_cpu();
+ return ret;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
Um.. there seems to be a pretty glaring problem here, in that AFAICT
in this revision of the series, this function is never invoked, and so
your breakpoint handling code will never be executed. i.e. the
changes to do_dabr to connect your code seem to be missing.
I realised it only after you pointed out...some remnants from the
previous version have caused it. While the patch should have treated
only ptrace in a special manner
Re: [PATCH 3/20] powerpc/mm: Add HW threads support to no_hash TLB management
for (cpu = cpu_first_thread_in_core(cpu);
cpu = cpu_last_thread_in_core(cpu); cpu++)
__clear_bit(id, stale_map[cpu]);
==
cpu = cpu_first_thread_in_core(cpu);
while (cpu = cpu_last_thread_in_core(cpu)) {
__clear_bit(id, stale_map[cpu]);
cpu++;
}
cpu = 0
cpu = 1
cpu++ (1)
cpu = 1
cpu++ (2)
cpu = 3
...
Ah right, /me takes snow out of his eyes... indeed, the
upper bound is fubar. Hrm. Allright, we'll use a temp.
Cheers,
Ben.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway
On Mon, 2009-08-03 at 14:14 +0100, David Woodhouse wrote: Do we care about that scenario? I think we might be able to fix it by setting the memory_limit when we allow pci_set_dma_mask() to succeed? That will effectively prevent the addition of memory that our crappy device can't reach, won't it? We don't support hotplug memory on those machines anyway, do we ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Kernel fault with simple UIO interrupt driver in 2.6.30.4
On Mon, 2009-08-03 at 15:07 +0200, Frank Prepelica wrote: Hi all, due to a new revision of our custimized board, i need to port our current kernel (2.6.24) to the latest kernel version 2.6.30.4. Among other things the UIO interrupt driver makes some trouble. The driver runs smoothly on 2.6.24 but I'll get kernel faults when running in 2.6.30.4. You seem to have forgotten to post the log of the oops :) cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
