* Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register access
From: Kumar Gala @ 2010-10-14 12:57 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: alexandre.bounine, linuxppc-dev, Xie Shaohui-B21989
In-Reply-To: <F9BD3E0A8083BE4ABAA94D7EDD7E3F633346A7@zch01exm26.fsl.freescale.net>
On Oct 14, 2010, at 2:10 AM, Li Yang-R58472 wrote:
>> Subject: Re: [PATCH 2/3] fsl_rio: fix non-standard HID1 register =
access
>>=20
>>=20
>> On Oct 13, 2010, at 9:04 PM, Shaohui Xie wrote:
>>=20
>>> From: Li Yang <leoli@freescale.com>
>>>=20
>>> The access to HID1 register is only legitimate for e500 v1/v2 cores.
>>> Also fixes magic number.
>>>=20
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>> Signed-off-by: Shaohui Xie <b21989@freescale.com>
>>> ---
>>> arch/powerpc/sysdev/fsl_rio.c | 9 ++++++---
>>> 1 files changed, 6 insertions(+), 3 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/sysdev/fsl_rio.c
>>> b/arch/powerpc/sysdev/fsl_rio.c index 4127636..dfff3b7 100644
>>> --- a/arch/powerpc/sysdev/fsl_rio.c
>>> +++ b/arch/powerpc/sysdev/fsl_rio.c
>>> @@ -1537,9 +1537,12 @@ int fsl_rio_setup(struct platform_device =
*dev)
>>> #ifdef CONFIG_E500
>>> saved_mcheck_exception =3D ppc_md.machine_check_exception;
>>> ppc_md.machine_check_exception =3D fsl_rio_mcheck_exception; =
-#endif
>>> - /* Ensure that RFXE is set */
>>> - mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | 0x20000));
>>> +
>>> +#ifndef CONFIG_PPC_E500MC
>>> + /* Ensure that RFXE is set on e500 v1/v2 */
>>> + mtspr(SPRN_HID1, (mfspr(SPRN_HID1) | HID1_RFXE)); #endif /*
>>> +!PPC_E500MC */ #endif /* E500 */
>>=20
>> I've never really been happy with this code. We really should set
>> HID1_RFXE in cpu_setup_fsl_booke.S instead.
>=20
> But this bit is not recommended to be set unless necessary. And it is =
only required by SRIO for now.
Than wrap it in a CONFIG_RAPIDIO in cpu_setup_fsl_booke.S
- k
^ permalink raw reply
* Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: divya @ 2010-10-14 13:25 UTC (permalink / raw)
To: systemtap, linuxppc-dev
While running systemtap tests on the p6 machine , against the kernel version 2.6.36-rc7-git3
Oops occured , here are the call trace
BUG: spinlock bad magic on CPU#6, stapio/20398
-- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res
lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
Call Trace:
[c0000001effbfab0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
[c0000001effbfb60] [c0000000002c9274] .spin_bug+0xb0/0xd4
[c0000001effbfbf0] [c0000000002c953c] .do_raw_spin_lock+0x48/0x184
[c0000001effbfc90] [c00000000054af78] ._raw_spin_lock+0x10/0x24
[c0000001effbfd00] [d000000003015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
[c0000001effbfec0] [c0000000000952d0] .__do_softirq+0xe4/0x1b4
[c0000001effbff90] [c00000000002a7a8] .call_do_softirq+0x14/0x24
[c00000010af1f560] [c00000000000dde4] .do_softirq+0x88/0xf0
[c00000010af1f600] [c000000000095030] .irq_exit+0x50/0xac
[c00000010af1f680] [c000000000027660] .timer_interrupt+0x110/0x13c
[c00000010af1f710] [c000000000003718] decrementer_common+0x118/0x180
--- Exception: 901 at .smp_call_function_many+0x284/0x2d0
LR = .smp_call_function_many+0x268/0x2d0
[c00000010af1fae0] [c0000000000c55c4] .smp_call_function+0x3c/0x54
[c00000010af1fb60] [c000000000094cdc] .on_each_cpu+0x24/0x84
[c00000010af1fc00] [d000000003016738] ._stp_ctl_write_cmd+0x3b0/0x9c8 [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c00000010af1fce0] [c0000000001585f4] .vfs_write+0xd0/0x1b8
[c00000010af1fd80] [c0000000001587e4] .SyS_write+0x58/0xa0
[c00000010af1fe30] [c0000000000085b4] syscall_exit+0x0/0x40
------------[ cut here ]------------
kernel BUG at kernel/timer.c:681!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
last sysfs file: /sys/module/stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798/sections/__param
Modules linked in: stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798 ipv6 fuse loop dm_mod ibmveth sg sr_mod cdrom sd_mod crc_t10dif ibmvscsic scsi_transport_srp scsi_tgt scsi_mod [last unloaded: stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
NIP: c00000000009d090 LR: d00000000301597c CTR: c00000000009cfb0
REGS: c0000001effbf9d0 TRAP: 0700 Not tainted (2.6.36-rc7-git3-autotest)
MSR: 8000000000029032<EE,ME,CE,IR,DR> CR: 28000482 XER: 00000002
TASK = c000000103422410[20398] 'stapio' THREAD: c00000010af1c000 CPU: 6
GPR00: 0000000000000001 c0000001effbfc50 c000000000a31660 c000000000fcfa48
GPR04: 000000010000c8da 0000000000000070 0000000000000002 0000000000000000
GPR08: ffffffffffffffff c000000000ac7bf8 0000000000000006 c00000000009cfb0
GPR12: d000000003017090 c00000000f600f00 0000000010008fd8 0000000010008ff8
GPR16: 0000000000000000 c000000000a91180 0000000000000000 0000000000000001
GPR20: c00000010edb9030 c00000010edb9430 c00000010edb9830 c00000010edb9c30
GPR24: 0000000000000001 001167a5b590dc41 c000000000fcfa18 000000010000c8da
GPR28: c000000000fcfa48 d00000000301597c c0000000009a6470 000000010000c8da
NIP [c00000000009d090] .mod_timer+0xe0/0x24c
LR [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
Call Trace:
[c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
[c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
[c0000001effbfec0] [c0000000000952d0] .__do_softirq+0xe4/0x1b4
[c0000001effbff90] [c00000000002a7a8] .call_do_softirq+0x14/0x24
[c00000010af1f560] [c00000000000dde4] .do_softirq+0x88/0xf0
[c00000010af1f600] [c000000000095030] .irq_exit+0x50/0xac
[c00000010af1f680] [c000000000027660] .timer_interrupt+0x110/0x13c
[c00000010af1f710] [c000000000003718] decrementer_common+0x118/0x180
--- Exception: 901 at .smp_call_function_many+0x284/0x2d0
LR = .smp_call_function_many+0x268/0x2d0
[c00000010af1fae0] [c0000000000c55c4] .smp_call_function+0x3c/0x54
[c00000010af1fb60] [c000000000094cdc] .on_each_cpu+0x24/0x84
[c00000010af1fc00] [d000000003016738] ._stp_ctl_write_cmd+0x3b0/0x9c8 [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c00000010af1fce0] [c0000000001585f4] .vfs_write+0xd0/0x1b8
[c00000010af1fd80] [c0000000001587e4] .SyS_write+0x58/0xa0
[c00000010af1fe30] [c0000000000085b4] syscall_exit+0x0/0x40
Instruction dump:
7ffb4878 f9210070 e93e8078 80090000 2f800000 419e0010 7fa4eb78 7f83e378
4bfffcb1 e81c0020 7c000074 7800d182<0b000000> 7f83e378 38810070 3b400000
Kernel panic - not syncing: Fatal exception in interrupt
Call Trace:
[c0000001effbf5b0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
[c0000001effbf660] [c000000000552094] .panic+0x9c/0x204
[c0000001effbf700] [c000000000028974] .die+0x268/0x2ac
[c0000001effbf7a0] [c000000000028ca8] ._exception+0x88/0x174
[c0000001effbf960] [c000000000004f8c] program_check_common+0x10c/0x180
--- Exception: 700 at .mod_timer+0xe0/0x24c
LR = .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
[c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
[c0000001effbfec0] [c0000000000952d0] .__do_softirq+0xe4/0x1b4
[c0000001effbff90] [c00000000002a7a8] .call_do_softirq+0x14/0x24
[c00000010af1f560] [c00000000000dde4] .do_softirq+0x88/0xf0
[c00000010af1f600] [c000000000095030] .irq_exit+0x50/0xac
[c00000010af1f680] [c000000000027660] .timer_interrupt+0x110/0x13c
[c00000010af1f710] [c000000000003718] decrementer_common+0x118/0x180
--- Exception: 901 at .smp_call_function_many+0x284/0x2d0
LR = .smp_call_function_many+0x268/0x2d0
[c00000010af1fae0] [c0000000000c55c4] .smp_call_function+0x3c/0x54
[c00000010af1fb60] [c000000000094cdc] .on_each_cpu+0x24/0x84
[c00000010af1fc00] [d000000003016738] ._stp_ctl_write_cmd+0x3b0/0x9c8 [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
[c00000010af1fce0] [c0000000001585f4] .vfs_write+0xd0/0x1b8
[c00000010af1fd80] [c0000000001587e4] .SyS_write+0x58/0xa0
[c00000010af1fe30] [c0000000000085b4] syscall_exit+0x0/0x40
Rebooting in 180 seconds..-- 0:conmux-control -- time-stamp -- Oct/13/10 2:51:18 --
Thanks
Divya
^ permalink raw reply
* [PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
From: Kumar Gala @ 2010-10-14 13:25 UTC (permalink / raw)
To: linuxppc-dev
The p4080, p3041, and p5020 (32-bit) SoCs from Freescale use the e500mc
defconfig. There are enough minor differences between these SoCs and
the existing P1xxx/P2xxx and MPC85xx SoCs to warrant a new defconfig.
The biggest of those is the cachline size being different which we
handle at compile time.
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
arch/powerpc/configs/e500mc_smp_defconfig | 178 +++++++++++++++++++++++++++++
1 files changed, 178 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/configs/e500mc_smp_defconfig
diff --git a/arch/powerpc/configs/e500mc_smp_defconfig b/arch/powerpc/configs/e500mc_smp_defconfig
new file mode 100644
index 0000000..39b5871
--- /dev/null
+++ b/arch/powerpc/configs/e500mc_smp_defconfig
@@ -0,0 +1,178 @@
+CONFIG_PPC_85xx=y
+CONFIG_SMP=y
+CONFIG_NR_CPUS=8
+CONFIG_EXPERIMENTAL=y
+CONFIG_SYSVIPC=y
+CONFIG_POSIX_MQUEUE=y
+CONFIG_BSD_PROCESS_ACCT=y
+CONFIG_AUDIT=y
+CONFIG_RCU_TRACE=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_LOG_BUF_SHIFT=14
+CONFIG_BLK_DEV_INITRD=y
+# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_EMBEDDED=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_KALLSYMS_EXTRA_PASS=y
+CONFIG_PERF_EVENTS=y
+CONFIG_SLAB=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+# CONFIG_BLK_DEV_BSG is not set
+CONFIG_P3041_DS=y
+CONFIG_P4080_DS=y
+CONFIG_P5020_DS=y
+CONFIG_HIGHMEM=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_BINFMT_MISC=m
+CONFIG_MATH_EMULATION=y
+CONFIG_SPARSE_IRQ=y
+CONFIG_PCI=y
+CONFIG_PCIEPORTBUS=y
+# CONFIG_PCIEASPM is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_XFRM_USER=y
+CONFIG_XFRM_SUB_POLICY=y
+CONFIG_XFRM_STATISTICS=y
+CONFIG_NET_KEY=y
+CONFIG_NET_KEY_MIGRATE=y
+CONFIG_INET=y
+CONFIG_IP_MULTICAST=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_MULTIPATH=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+CONFIG_IP_PNP_BOOTP=y
+CONFIG_IP_PNP_RARP=y
+CONFIG_NET_IPIP=y
+CONFIG_NET_IPGRE=y
+CONFIG_NET_IPGRE_BROADCAST=y
+CONFIG_IP_MROUTE=y
+CONFIG_IP_PIMSM_V1=y
+CONFIG_IP_PIMSM_V2=y
+CONFIG_ARPD=y
+CONFIG_INET_AH=y
+CONFIG_INET_ESP=y
+CONFIG_INET_IPCOMP=y
+# CONFIG_INET_LRO is not set
+CONFIG_IPV6=y
+CONFIG_IP_SCTP=m
+CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
+CONFIG_MTD=y
+CONFIG_MTD_CONCAT=y
+CONFIG_MTD_PARTITIONS=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_OF_PARTS=y
+CONFIG_MTD_CHAR=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_AMDSTD=y
+CONFIG_MTD_PHYSMAP_OF=y
+CONFIG_MTD_M25P80=y
+CONFIG_PROC_DEVICETREE=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_NBD=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_BLK_DEV_RAM_SIZE=131072
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_ST=y
+CONFIG_BLK_DEV_SR=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SYM53C8XX_2=y
+CONFIG_ATA=y
+CONFIG_SATA_AHCI=y
+CONFIG_SATA_SIL24=y
+CONFIG_SATA_SIL=y
+CONFIG_PATA_SIL680=y
+CONFIG_NETDEVICES=y
+CONFIG_VITESSE_PHY=y
+CONFIG_FIXED_PHY=y
+CONFIG_NET_ETHERNET=y
+CONFIG_E1000=y
+CONFIG_E1000E=y
+CONFIG_FSL_PQ_MDIO=y
+# CONFIG_INPUT_MOUSEDEV is not set
+# CONFIG_INPUT_KEYBOARD is not set
+# CONFIG_INPUT_MOUSE is not set
+CONFIG_SERIO_LIBPS2=y
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_8250_EXTENDED=y
+CONFIG_SERIAL_8250_MANY_PORTS=y
+CONFIG_SERIAL_8250_DETECT_IRQ=y
+CONFIG_SERIAL_8250_RSA=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_HW_RANDOM=y
+CONFIG_NVRAM=y
+CONFIG_I2C=y
+CONFIG_I2C_MPC=y
+CONFIG_SPI=y
+CONFIG_SPI_GPIO=y
+# CONFIG_HWMON is not set
+CONFIG_VIDEO_OUTPUT_CONTROL=y
+CONFIG_USB_HID=m
+CONFIG_USB=y
+CONFIG_USB_DEVICEFS=y
+CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_FSL=y
+CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_HCD_PPC_OF_BE=y
+CONFIG_USB_OHCI_HCD_PPC_OF_LE=y
+CONFIG_USB_STORAGE=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_OF=y
+CONFIG_MMC_SDHCI_OF_ESDHC=y
+CONFIG_EDAC=y
+CONFIG_EDAC_MM_EDAC=y
+CONFIG_EDAC_MPC85XX=y
+CONFIG_RTC_CLASS=y
+CONFIG_RTC_DRV_DS3232=y
+CONFIG_RTC_DRV_CMOS=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_ISO9660_FS=m
+CONFIG_JOLIET=y
+CONFIG_ZISOFS=y
+CONFIG_UDF_FS=m
+CONFIG_MSDOS_FS=m
+CONFIG_VFAT_FS=y
+CONFIG_NTFS_FS=y
+CONFIG_PROC_KCORE=y
+CONFIG_TMPFS=y
+CONFIG_JFFS2_FS=y
+CONFIG_CRAMFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3=y
+CONFIG_NFS_V4=y
+CONFIG_ROOT_NFS=y
+CONFIG_NFSD=m
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_MAC_PARTITION=y
+CONFIG_NLS_ISO8859_1=y
+CONFIG_NLS_UTF8=m
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_DEBUG_KERNEL=y
+CONFIG_DEBUG_SHIRQ=y
+CONFIG_DETECT_HUNG_TASK=y
+CONFIG_DEBUG_INFO=y
+CONFIG_SYSCTL_SYSCALL_CHECK=y
+CONFIG_CRYPTO_NULL=y
+CONFIG_CRYPTO_PCBC=m
+CONFIG_CRYPTO_MD4=y
+CONFIG_CRYPTO_SHA256=y
+CONFIG_CRYPTO_SHA512=y
+CONFIG_CRYPTO_AES=y
+# CONFIG_CRYPTO_ANSI_CPRNG is not set
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] powerpc/fsl-booke: Add e500mc smp defconfig
From: Timur Tabi @ 2010-10-14 13:51 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <1287062710-8621-1-git-send-email-galak@kernel.crashing.org>
On Thu, Oct 14, 2010 at 8:25 AM, Kumar Gala <galak@kernel.crashing.org> wrote:
> +CONFIG_MATH_EMULATION=y
Don't these chips have hardware FP?
> +CONFIG_E1000=y
> +CONFIG_E1000E=y
Are you sure you want these on by default? We may use the E1000 cards
in-house, but I don't know if our customers do.
> +CONFIG_MSDOS_FS=m
> +CONFIG_VFAT_FS=y
> +CONFIG_NTFS_FS=y
These should probably be off as well.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
From: Kumar Gala @ 2010-10-14 13:55 UTC (permalink / raw)
To: grant.likely; +Cc: linuxppc-dev, spi-devel-general
We get the following when building on ppc64 due to lack of include of
<asm/io.h>:
In file included from drivers/spi/spi_fsl_espi.c:25:0:
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function 'out_be32'
drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function 'in_be32'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function 'iounmap'
drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function 'ioremap'
drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from integer without a cast
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
drivers/spi/spi_fsl_lib.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
index 15aa6c2..281e060 100644
--- a/drivers/spi/spi_fsl_lib.h
+++ b/drivers/spi/spi_fsl_lib.h
@@ -18,6 +18,8 @@
#ifndef __SPI_FSL_LIB_H__
#define __SPI_FSL_LIB_H__
+#include <asm/io.h>
+
/* SPI/eSPI Controller driver's private data. */
struct mpc8xxx_spi {
struct device *dev;
--
1.7.2.3
^ permalink raw reply related
* Re: RTC rtc-cmos.c : Fix warning on PowerPC
From: srikanth krishnakar @ 2010-10-14 14:03 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Linuxppc-embedded
In-Reply-To: <24020.1286940298@neuling.org>
>From 8435e5876fc3d629406c63b85bff82c25fc4bf75 Mon Sep 17 00:00:00 2001
From: Srikanth Krishnakar <skrishna@mvista.com>
Date: Fri, 8 Oct 2010 18:07:06 +0530
Subject: [PATCH] RTC: rtc-cmos.c: Fix warning on PowerPC
The following warning is seen while compilation of PowerPC kernel:
CC drivers/rtc/rtc-cmos.o
drivers/rtc/rtc-cmos.c:697:2: warning: #warning Assuming 128 bytes
of RTC+NVRAM address space, not 64 bytes.
Fix it by adding defined(__powerpc__).
Signed-off-by: Srikanth Krishnakar <skrishna@mvista.com>
---
drivers/rtc/rtc-cmos.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 5856167..7e6ce62 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -687,7 +687,8 @@ cmos_do_probe(struct device *dev, struct resource
*ports, int rtc_irq)
#if defined(CONFIG_ATARI)
address_space = 64;
#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) \
- || defined(__sparc__) || defined(__mips__)
+ || defined(__sparc__) || defined(__mips__) \
+ || defined(__powerpc__)
address_space = 128;
#else
#warning Assuming 128 bytes of RTC+NVRAM address space, not 64 bytes.
--
1.6.3.3.333.gdf68
^ permalink raw reply related
* Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
From: Grant Likely @ 2010-10-14 14:12 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <1287064547-8876-1-git-send-email-galak@kernel.crashing.org>
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
> We get the following when building on ppc64 due to lack of include of
> <asm/io.h>:
Is this an immediate problem (merge for .36), or is it a linux-next thing?
g.
>
> In file included from drivers/spi/spi_fsl_espi.c:25:0:
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
> drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function 'out_be32'
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
> drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function 'in_be32'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
> drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function 'iounmap'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
> drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function 'ioremap'
> drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from integer without a cast
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/spi/spi_fsl_lib.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
> index 15aa6c2..281e060 100644
> --- a/drivers/spi/spi_fsl_lib.h
> +++ b/drivers/spi/spi_fsl_lib.h
> @@ -18,6 +18,8 @@
> #ifndef __SPI_FSL_LIB_H__
> #define __SPI_FSL_LIB_H__
>
> +#include <asm/io.h>
> +
> /* SPI/eSPI Controller driver's private data. */
> struct mpc8xxx_spi {
> struct device *dev;
> --
> 1.7.2.3
>
^ permalink raw reply
* Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
From: Kumar Gala @ 2010-10-14 14:41 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <20101014141244.GA4312@angua.secretlab.ca>
On Oct 14, 2010, at 9:12 AM, Grant Likely wrote:
> On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
>> We get the following when building on ppc64 due to lack of include of
>> <asm/io.h>:
>
> Is this an immediate problem (merge for .36), or is it a linux-next thing?
>
> g.
.37 / next is fine.
- k
^ permalink raw reply
* Re: [PATCH] spi/fsl_spi: Fix compile errors when building on ppc64
From: Grant Likely @ 2010-10-14 14:47 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, spi-devel-general
In-Reply-To: <1287064547-8876-1-git-send-email-galak@kernel.crashing.org>
On Thu, Oct 14, 2010 at 08:55:47AM -0500, Kumar Gala wrote:
> We get the following when building on ppc64 due to lack of include of
> <asm/io.h>:
Applied.
g.
>
> In file included from drivers/spi/spi_fsl_espi.c:25:0:
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_write_reg':
> drivers/spi/spi_fsl_lib.h:88:2: error: implicit declaration of function 'out_be32'
> drivers/spi/spi_fsl_lib.h: In function 'mpc8xxx_spi_read_reg':
> drivers/spi/spi_fsl_lib.h:93:2: error: implicit declaration of function 'in_be32'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_remove':
> drivers/spi/spi_fsl_espi.c:571:2: error: implicit declaration of function 'iounmap'
> drivers/spi/spi_fsl_espi.c: In function 'fsl_espi_probe':
> drivers/spi/spi_fsl_espi.c:602:2: error: implicit declaration of function 'ioremap'
> drivers/spi/spi_fsl_espi.c:602:24: warning: assignment makes pointer from integer without a cast
>
> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
> ---
> drivers/spi/spi_fsl_lib.h | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi_fsl_lib.h b/drivers/spi/spi_fsl_lib.h
> index 15aa6c2..281e060 100644
> --- a/drivers/spi/spi_fsl_lib.h
> +++ b/drivers/spi/spi_fsl_lib.h
> @@ -18,6 +18,8 @@
> #ifndef __SPI_FSL_LIB_H__
> #define __SPI_FSL_LIB_H__
>
> +#include <asm/io.h>
> +
> /* SPI/eSPI Controller driver's private data. */
> struct mpc8xxx_spi {
> struct device *dev;
> --
> 1.7.2.3
>
^ permalink raw reply
* eSDHC controller driver on MPC8308rdb
From: Maria Johansen @ 2010-10-14 14:42 UTC (permalink / raw)
To: linuxppc-dev
SGVsbG8sDQooYXBvbG9naWVzIGZvciB3cml0aW5nIHN1Y2ggYSBsb25nIGUtbWFpbCwgaG9wZSB5
b3UgY2FuIGJvdGhlciB0byByZWFkIGl0IGFsbCDimLogKQ0KSSBoYXZlIHNvbWUgZGlmZmljdWx0
aWVzIHdpdGggdGhlIGVTREhDIGNvbnRyb2xsZXIgZHJpdmVyIHVzZWQgb24gYSBNUEM4MzA4IGV2
YWx1YXRpb24gYm9hcmQgd2l0aCBrZXJuZWwgMi42LjM2LXJjNywgYW5kIGhvcGUgdGhhdCBzb21l
IG9mIHlvdSBtYXkgYmUgYWJsZSB0byBoZWxwIG1lIHdpdGggdGhlIGRlYnVnZ2luZy4gDQoNClRo
ZSBkcml2ZXIgaXMgbG9hZGVkIHByb3Blcmx5LCBhbmQgYmluZHMgdG8gdGhlIGVTREhDIGNvbnRy
b2xsZXIgd2l0aG91dCBwcm9ibGVtcy4gV2hlbiBpbnNlcnRpbmcgYSBzZC1jYXJkIGl0IGlzIGJv
dW5kIHRvIHRoZSAgbW1jYmxrLWRyaXZlciwgc28gbm8gcHJvYmxlbXMgdGhlcmUgZWl0aGVyLiAg
DQoNCkhvd2V2ZXIsIEkgYW0gbm90IGFibGUgdG8gcmVhZCBub3Igd3JpdGUgdG8gdGhlIGNhcmQs
IEkgaGF2ZSBhdHRhY2hlZCBvdXRwdXQgd2l0aCBlcnJvciBtZXNzYWdlcyBiZWxvdzoNCg0KKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKg0K
bW1jMDogbmV3IFNESEMgY2FyZCBhdCBhZGRyZXNzIDkxNTUNCm1tY2JsazA6IG1tYzA6OTE1NSBT
RDA0RyAzLjY5IEdpQg0KbW1jMDogVG9vIGxhcmdlIHRpbWVvdXQgcmVxdWVzdGVkIQ0KbW1jYmxr
MDogcmV0cnlpbmcgdXNpbmcgc2luZ2xlIGJsb2NrIHJlYWQNCm1tYzA6IFRvbyBsYXJnZSB0aW1l
b3V0IHJlcXVlc3RlZCENCm1tY2JsazA6IGVycm9yIC04NCBzZW5kaW5nIHN0YXR1cyBjb21hbmQN
Cm1tY2JsazA6IGVycm9yIC0xMTAgc2VuZGluZyByZWFkL3dyaXRlIGNvbW1hbmQsIHJlc3BvbnNl
IDB4MCwgY2FyZCBzdGF0dXMgMHgwDQplbmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbW1jYmxr
MCwgc2VjdG9yIDANCm1tYzA6IFRvbyBsYXJnZSB0aW1lb3V0IHJlcXVlc3RlZCENCm1tY2JsazA6
IGVycm9yIC04NCBzZW5kaW5nIHN0YXR1cyBjb21hbmQNCm1tY2JsazA6IGVycm9yIC0xMTAgc2Vu
ZGluZyByZWFkL3dyaXRlIGNvbW1hbmQsIHJlc3BvbnNlIDB4MCwgY2FyZCBzdGF0dXMgMHgwDQpl
bmRfcmVxdWVzdDogSS9PIGVycm9yLCBkZXYgbW1jYmxrMCwgc2VjdG9yIDENCuKApi4uPHRoaXMg
Y29udGludWVzIHVwIHRvIHNlY3RvciA3IGJlZm9yZSBzdGFydGluZyBhbmV3Pg0KDQpEZWJ1ZyBv
dXRwdXQgd2l0aCBubyBTRC1jYXJkOg0KKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKg0KbW1jMDogY2xvY2sgMEh6IGJ1c21vZGUgMSBwb3dl
cm1vZGUgMSBjcyAwIFZkZCAyMCB3aWR0aCAwIHRpbWluZyAwDQptbWMwOiBjbG9jayA0MDAwMDBI
eiBidXNtb2RlIDEgcG93ZXJtb2RlIDIgY3MgMCBWZGQgMjAgd2lkdGggMCB0aW1pbmcgMA0Kb2Y6
c2RoY2ktb2YgZTAwMmUwMDAuc2RoY2k6IGRlc2lyZWQgU0QgY2xvY2s6IDQwMDAwMCwgYWN0dWFs
OiAwDQptbWMwOiBzdGFydGluZyBDTUQ1MiBhcmcgMDAwMDBjMDAgZmxhZ3MgMDAwMDAxOTUNCnNk
aGNpIFtzZGhjaV9pcnEoKV06ICoqKiBtbWMwIGdvdCBpbnRlcnJ1cHQ6IDB4MDAwMTAwMDENCm1t
YzA6IHJlcSBkb25lIChDTUQ1Mik6IC0xMTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAwIDAw
MDAwMDAwDQptbWMwOiBzdGFydGluZyBDTUQ1MiBhcmcgODAwMDBjMDggZmxhZ3MgMDAwMDAxOTUN
CnNkaGNpIFtzZGhjaV9pcnEoKV06ICoqKiBtbWMwIGdvdCBpbnRlcnJ1cHQ6IDB4MDAwMTAwMDEN
Cm1tYzA6IHJlcSBkb25lIChDTUQ1Mik6IC0xMTA6IDAwMDAwMDAwIDAwMDAwMDAwIDAwMDAwMDAw
IDAwMDAwMDAwDQptbWMwOiBjbG9jayA0MDAwMDBIeiBidXNtb2RlIDEgcG93ZXJtb2RlIDIgY3Mg
MSBWZGQgMjAgd2lkdGggMCB0aW1pbmcgMA0KbW1jMDogc3RhcnRpbmcgQ01EMCBhcmcgMDAwMDAw
MDAgZmxhZ3MgMDAwMDAwYzANCnNkaGNpIFtzZGhjaV9pcnEoKV06ICoqKiBtbWMwIGdvdCBpbnRl
cnJ1cHQ6IDB4MDAwMDAwMDENCm1tYzA6IHJlcSBkb25lIChDTUQwKTogMDogMDAwMDAwMDAgMDAw
MDAwMDAgMDAwMDAwMDAgMDAwMDAwMDANCm1tYzA6IGNsb2NrIDQwMDAwMEh6IGJ1c21vZGUgMSBw
b3dlcm1vZGUgMiBjcyAwIFZkZCAyMCB3aWR0aCAwIHRpbWluZyAwDQptbWMwOiBzdGFydGluZyBD
TUQ4IGFyZyAwMDAwMDFhYSBmbGFncyAwMDAwMDJmNQ0Kc2RoY2kgW3NkaGNpX2lycSgpXTogKioq
IG1tYzAgZ290IGludGVycnVwdDogMHgwMDAxMDAwMQ0KbW1jMDogcmVxIGRvbmUgKENNRDgpOiAt
MTEwOiAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMCAwMDAwMDAwMA0KbW1jMDogc3RhcnRpbmcg
Q01ENSBhcmcgMDAwMDAwMDAgZmxhZ3MgMDAwMDAyZTENCnNkaGNpIFtzZGhjaV9pcnEoKV06ICoq
KiBtbWMwIGdvdCBpbnRlcnJ1cHQ6IDB4MDAwMTAwMDENCm1tYzA6IHJlcSBmYWlsZWQgKENNRDUp
OiAtMTEwLCByZXRyeWluZy4uLg0Kc2RoY2kgW3NkaGNpX2lycSgpXTogKioqIG1tYzAgZ290IGlu
dGVycnVwdDogMHgwMDAxMDAwMQ0KbW1jMDogcmVxIGZhaWxlZCAoQ01ENSk6IC0xMTAsIHJldHJ5
aW5nLi4uDQpzZGhjaSBbc2RoY2lfaXJxKCldOiAqKiogbW1jMCBnb3QgaW50ZXJydXB0OiAweDAw
MDEwMDAxDQptbWMwOiByZXEgZmFpbGVkIChDTUQ1KTogLTExMCwgcmV0cnlpbmcuLi4NCuKApg0K
DQpJIGhhdmUgdGhlIGZvbGxvd2luZyBpbiBteSBkdHM6DQogICAgICAgc2RoY2lAMmUwMDAgew0K
CQljb21wYXRpYmxlID0gImZzbCxtcGM4MzA4LWVzZGhjIiwgImZzbCxlc2RoYyI7DQoJCXJlZyA9
IDwweDJlMDAwIDB4MTAwMD47DQoJCWludGVycnVwdHMgPSA8NDIgMHg4PjsNCgkJaW50ZXJydXB0
LXBhcmVudCA9IDwmaXBpYz47DQoJCWNsb2NrLWZyZXF1ZW5jeSA9IDwwPjsNCgl9Ow0KDQoNCkNv
dWxkIHRoaXMgYmUgYSBwcm9ibGVtIHJlbGF0ZWQgdGhlIGVTREhDIGNvbnRyb2xsZXIgKG9yIHRo
ZSBkcml2ZXIpLCBvciBpcyBpdCB0aGUgbWVtb3J5IGNhcmQ/IChhIDRHQiBTYW5EaXNrIEV4dHJl
bWUgU0RIQyBjYXJkLCB3aGljaCB1bmZvcnR1bmF0ZWx5IGlzIHRoZSBvbmx5IGNhcmQgSSBoYXZl
IGF2YWlsYWJsZSBhdCB0aGUgbW9tZW50LikNCkkgd2lsbCBrZWVwIGRpZ2dpbmcgaW50byBkcml2
ZXJzL21tYy9ob3N0L3NkaGNpLmMgaW4gc2VhcmNoIG9mIGEgc29sdXRpb24sIGFuZCBhbnkgdGlw
cyB0byBob3cgSSBzaG91bGQgcHJvY2VlZCB3b3VsZCBiZSBncmVhdGx5IGFwcHJlY2lhdGVkIQ0K
DQotLQ0KTWFyaWEgDQo=
^ permalink raw reply
* Re: [PATCH] powerpc/5121: pdm360ng: fix touch irq if 8xxx gpio driver is enabled
From: Anatolij Gustschin @ 2010-10-14 14:55 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev
In-Reply-To: <1284581577-2217-1-git-send-email-agust@denx.de>
Hi Grant,
On Wed, 15 Sep 2010 22:12:57 +0200
Anatolij Gustschin <agust@denx.de> wrote:
> Enabling the MPC8xxx GPIO driver with MPC512x GPIO extension
> breaks touch screen support on this board since the GPIO
> interrupt will be mapped to 8xxx GPIO irq host resulting in
> a not requestable interrupt in the touch screen driver. Fix
> it by mapping the touch interrupt on 8xxx GPIO irq host.
>
> Signed-off-by: Anatolij Gustschin <agust@denx.de>
> ---
> arch/powerpc/platforms/512x/pdm360ng.c | 26 ++++++++++++++++++++++----
> 1 files changed, 22 insertions(+), 4 deletions(-)
Can this patch go in for 2.6.37 ?
Thanks,
Anatolij
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-14 15:51 UTC (permalink / raw)
To: tiejun.chen; +Cc: david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <4CB6788D.60705@windriver.com>
On Thu, 14 Oct 2010 11:27:09 +0800
"tiejun.chen" <tiejun.chen@windriver.com> wrote:
> tiejun.chen wrote:
> > Scott Wood wrote:
> >> On Wed, 13 Oct 2010 09:17:01 +0800
> >> "tiejun.chen" <tiejun.chen@windriver.com> wrote:
> >>
> >>> Scott Wood wrote:
> >>>> The crash is happening somewhere in mpic_set_irq_type():
> >>> Agreed. That is just where I pointed out on my email replied for OOPS. To enable
> >>> DBG to figure out 'src' and 'mpic->irq_count' from the file,
> >>> arch/powerpc/sysdev/mpic.c, .
> >>> ======
> >>> int mpic_set_irq_type(unsigned int virq, unsigned int flow_type)
> >>> {
> >>> ......
> >>> if (src >= mpic->irq_count)
> >>> return -EINVAL;
> >>> ^
> >>> I think this OOPS may be from here.
> >> No, it's after that. His board code is using the mpic's "isu" remapping
> >
> > I means OOPS is *from* here. According to David's call trace,
> > mpic_set_irq_type() is the last issued function. And that corresponding return
> > value, R3, is '0xffffffea', -22, and also '-EINVAL'.
Just because that value is in r3 doesn't mean that src >=
mpic->irq_count.
Consider something like:
cmplw r4, r5
li r3, -EINVAL
bgelr
...
-Scott
^ permalink raw reply
* Re: [PATCH 1/3 v4] P4080/eLBC: Make Freescale elbc interrupt common to elbc devices
From: Scott Wood @ 2010-10-14 16:02 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Lan Chunhe-B25806, linuxppc-dev,
linux-mtd, akpm, dwmw2, Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A2B0329@zch01exm23.fsl.freescale.net>
On Wed, 13 Oct 2010 23:43:38 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
> > Plus, I think the patch is not runtime bisectable (i.e. you
> > now do request_irq() here, but not removing it from the nand
> > driver, so nand will fail to probe).
> Nand driver does not need to request irq. It will use the irq requested by lbc.
> remember, other lbc device may also need to use this registered irq.
> It should not be removed in nand driver.
The point is that you need to make both changes in the same patch.
-Scott
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-14 16:22 UTC (permalink / raw)
To: Scott Wood; +Cc: tiejun.chen, david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014105126.08da9dd7@udp111988uds.am.freescale.net>
I may have a clue (you might not think so, but...):
I've configured the init thusly:
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
0, 256,
" MPIC ");
Which, as I read the code, should disable the ISU stuff.
I've seeing this on boot:
mpic: Setting up MPIC " MPIC " version 1.2 at e0040000, max 2 CPUs
mpic: ISU size: 88, shift: 7, mask: 7f
mpic: Initializing for 88 sources
Now, since the interrupt number I want is 224, which, last time I checked,
was > 88, this may be the root cause.
As I read the code:
/* Read feature register, calculate num CPUs and, for non-ISU
* MPICs, num sources as well. On ISU MPICs, sources are counted
* as ISUs are added
*/
greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK)
>> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
if (isu_size == 0)
mpic->num_sources =
((greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
>> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
So it would seem to me that the "greg_feature" is saying I have 88
interrupts.
I've tried setting the ISU size to 256:
mpic1 = mpic_alloc(np, res.start,
MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
256, 256,
" MPIC ");
And that kills the kernel as we init the mpic.
SO, I guess the question in, what sets "greg_feature", as it would seem to
be incorrect.
Or, am I on the wrong trail?
^ permalink raw reply
* Re: [PATCH 2/3 v4] P4080/mtd: Only make elbc nand driver detect nand flash partitions
From: Scott Wood @ 2010-10-14 16:01 UTC (permalink / raw)
To: Zang Roy-R61911
Cc: Wood Scott-B07421, dedekind1, Hu Mingkai-B21284,
Lan Chunhe-B25806, linuxppc-dev, linux-mtd, akpm, dwmw2,
Gala Kumar-B11780
In-Reply-To: <3850A844E6A3854C827AC5C0BEC7B60A2B02B7@zch01exm23.fsl.freescale.net>
On Wed, 13 Oct 2010 20:09:02 -0700
"Zang Roy-R61911" <r61911@freescale.com> wrote:
> > > > > + struct fsl_elbc_fcm_ctrl *elbc_fcm_ctrl = NULL;
> > > >
> > > > No need for = NULL.
> > > Any harm? Or just personal habit or style? Can you explain about
> why?
> >
> > Besides not wanting superfluous code on general principle, it could
> > hide a bug if in the future the real initialization is missing on some
> > code path. It would become a runtime NULL dereference rather than a
> > compiler warning.
>
> Not exactly.
> Per my understand, if the pointer will definitely be assigned in code
> path,
> it is not necessary to init it when define. for example,
>
> char c;
> char b;
> char *a;
> if (condition)
> a = &c;
> else
> a = &b;
> ...
>
> for other case, if the path will not ensure the pointer assignment, it
> will be inited
> when define to avoid warning. for example,
>
> char c;
> char *a = NULL;
> if (condition)
> a = &c;
> ...
Yes, but this patch looks like the former case, not the
latter. Is GCC giving a warning without the initializer?
-Scott
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-14 16:32 UTC (permalink / raw)
To: david.hagood; +Cc: tiejun.chen, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <dccb3790f1fbb04a8df74bd920e57580.squirrel@localhost>
On Thu, 14 Oct 2010 11:22:45 -0500
<david.hagood@gmail.com> wrote:
> As I read the code:
> /* Read feature register, calculate num CPUs and, for non-ISU
> * MPICs, num sources as well. On ISU MPICs, sources are counted
> * as ISUs are added
> */
> greg_feature = mpic_read(mpic->gregs, MPIC_INFO(GREG_FEATURE_0));
> mpic->num_cpus = ((greg_feature & MPIC_GREG_FEATURE_LAST_CPU_MASK)
> >> MPIC_GREG_FEATURE_LAST_CPU_SHIFT) + 1;
> if (isu_size == 0)
> mpic->num_sources =
> ((greg_feature & MPIC_GREG_FEATURE_LAST_SRC_MASK)
> >> MPIC_GREG_FEATURE_LAST_SRC_SHIFT) + 1;
> So it would seem to me that the "greg_feature" is saying I have 88
> interrupts.
>
> I've tried setting the ISU size to 256:
> mpic1 = mpic_alloc(np, res.start,
> MPIC_PRIMARY | MPIC_WANTS_RESET | MPIC_BIG_ENDIAN ,
> 256, 256,
> " MPIC ");
> And that kills the kernel as we init the mpic.
>
> SO, I guess the question in, what sets "greg_feature", as it would seem to
> be incorrect.
It comes from FRR[NIRQ]. It seems that this chip takes a
less-than-useful interpretation of what that field means -- it gives
the actual number of sources, not the size of the sparsely populated
array.
If you look at current kernels, you'll find an MPIC_BROKEN_FRR_NIRQS
flag to work around this.
It's not very clear to me what distinction the MPIC code is
trying to make between irq_count and num_sources in the first place,
though.
-Scott
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-14 17:20 UTC (permalink / raw)
To: Scott Wood; +Cc: tiejun.chen, david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014113230.051b967a@udp111988uds.am.freescale.net>
Hallelujah and Huzzah! I finally got my vector!
I back-ported the MPIC_BROKEN_FRR_NIRQS flag and code to our kernel, and
the kernel is now letting me have my vector! Now I can actually see if the
dang thing works!
THANK YOU EVERYBODY for putting up with me on this!
> It comes from FRR[NIRQ]. It seems that this chip takes a
> less-than-useful interpretation of what that field means -- it gives
> the actual number of sources, not the size of the sparsely populated
> array.
Perhaps you might want to have a talk with your cow-orkers there, Scott,
since this is a Freescale part.
> It's not very clear to me what distinction the MPIC code is
> trying to make between irq_count and num_sources in the first place,
> though.
/me looks at Scott's email again.
If you, working FOR Freescale, and following the Linux development
(presumably for some time) are confused, imagine what I've been going
through!
Hot damn, and time for a quick version control commit, a hot lunch, and
really testing the code.
Thanks again!
^ permalink raw reply
* [RFC PATCH] ppc: don't override CONFIG_PPC_PSERIES_DEBUG
From: Nishanth Aravamudan @ 2010-10-14 17:48 UTC (permalink / raw)
To: nacc
Cc: Michael Neuling, Frans Pop, linux-kernel, Paul Mackerras,
Anton Blanchard, Linas Vepstas, linuxppc-dev, Thomas Gleixner
These files undef DEBUG, but I think they were added before the ability
to control this from Kconfig. It's really annoying to only get some of
the debug messages!
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
---
Because the lpar and pci_dlpar code is pretty low-level & verbose,
perhaps it makes sense to add another Kconfig variable for really
low-level stuff? But it's annoying to have DEBUG *somewhat* effective,
especially in the EEH area when doing PCI stuff.
---
arch/powerpc/platforms/pseries/eeh.c | 2 --
arch/powerpc/platforms/pseries/lpar.c | 3 ---
arch/powerpc/platforms/pseries/pci_dlpar.c | 2 --
3 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/eeh.c b/arch/powerpc/platforms/pseries/eeh.c
index 34b7dc1..17a11c8 100644
--- a/arch/powerpc/platforms/pseries/eeh.c
+++ b/arch/powerpc/platforms/pseries/eeh.c
@@ -21,8 +21,6 @@
* Please address comments and feedback to Linas Vepstas <linas@austin.ibm.com>
*/
-#undef DEBUG
-
#include <linux/delay.h>
#include <linux/init.h>
#include <linux/list.h>
diff --git a/arch/powerpc/platforms/pseries/lpar.c b/arch/powerpc/platforms/pseries/lpar.c
index cf79b46..4b31a66 100644
--- a/arch/powerpc/platforms/pseries/lpar.c
+++ b/arch/powerpc/platforms/pseries/lpar.c
@@ -19,9 +19,6 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-/* Enables debugging of low-level hash table routines - careful! */
-#undef DEBUG
-
#include <linux/kernel.h>
#include <linux/dma-mapping.h>
#include <linux/console.h>
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index 4b7a062..5fcc92a 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -25,8 +25,6 @@
* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
-#undef DEBUG
-
#include <linux/pci.h>
#include <asm/pci-bridge.h>
#include <asm/ppc-pci.h>
--
1.7.1
^ permalink raw reply related
* Re: Questions on interrupt vector assignment on MPC8641D
From: Scott Wood @ 2010-10-14 17:50 UTC (permalink / raw)
To: david.hagood; +Cc: tiejun.chen, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <fac55e564d1f5b7e5398354939ec3b43.squirrel@localhost>
On Thu, 14 Oct 2010 12:20:55 -0500
<david.hagood@gmail.com> wrote:
> > It comes from FRR[NIRQ]. It seems that this chip takes a
> > less-than-useful interpretation of what that field means -- it gives
> > the actual number of sources, not the size of the sparsely populated
> > array.
> Perhaps you might want to have a talk with your cow-orkers there, Scott,
> since this is a Freescale part.
Well, it was a coworker who added the workaround, so I assume we're
already aware of the issue.
The description of NIRQ is vague enough that it's hard to argue that
Linux's expectations of what it means are justified.
-Scott
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Kumar Gala @ 2010-10-14 17:52 UTC (permalink / raw)
To: Tabi Timur-B04825; +Cc: linuxppc-dev, Gala Kumar-B11780
In-Reply-To: <5610599F537DD74A8D1F5CC946A75073034793B7@az33exm25.fsl.freescale.net>
On Oct 13, 2010, at 8:39 PM, Tabi Timur-B04825 wrote:
> Kumar Gala wrote:
>>>> arch/powerpc/configs/mpc85xx_defconfig | 3 +
>>>> arch/powerpc/configs/mpc85xx_smp_defconfig | 3 +
>>>> arch/powerpc/platforms/85xx/p1022_ds.c | 213 =
+++++++++++++++++++++++++++-
>>>> 3 files changed, 217 insertions(+), 2 deletions(-)
>> I dropped this because of chicken/egg issue with guts.h
>=20
> If you pull from alsa-next, it should resolve that.
>=20
> Either that, or ask the alsa guys to apply this patch instead.
Can you ask the alsa guys to pick it up. I'm happy to ack.
- k=
^ permalink raw reply
* Re: [PATCH 2/2] [v2] powerpc/85xx: add DIU support to the Freecale P1022DS reference board
From: Timur Tabi @ 2010-10-14 18:21 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala, alsa-devel mailing list, Mark Brown
In-Reply-To: <1286480203-28227-2-git-send-email-timur@freescale.com>
Mark, can you pick up this patch for us? Because it depends on
"powerpc: rename immap_86xx.h to fsl_guts.h, and add 85xx support", it
will break the build if we apply to powerpc-next.
You can grab the patch from http://patchwork.ozlabs.org/patch/67095/
On Thu, Oct 7, 2010 at 2:36 PM, Timur Tabi <timur@freescale.com> wrote:
> The Freescale P1022DS has an on-chip video controller called the DIU, and=
a
> driver for this device already exists. =A0Update the platform file for th=
e
> P1022DS reference board to enable the driver, and update the defconfig fo=
r
> Freescale MPC85xx boards to add the driver.
>
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
--=20
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: Questions on interrupt vector assignment on MPC8641D
From: david.hagood @ 2010-10-14 18:44 UTC (permalink / raw)
To: Scott Wood; +Cc: tiejun.chen, david.hagood, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20101014125010.5cfb4ee5@udp111988uds.am.freescale.net>
> Well, it was a coworker who added the workaround, so I assume we're
> already aware of the issue.
>
> The description of NIRQ is vague enough that it's hard to argue that
> Linux's expectations of what it means are justified.
>
Well, I now can actually interrupt the PPC from my host processor!
(well, it segfaulted, but's my fault for not actually initializing my work
queue structure. But I can get the interrupt into the part!)
So thanks to all.
I hope to get my code working, get past my delivery deadline on it, clean
it up so it matches The One True Way Of Laying Out Kernel Code, and post
it here for everybody to point and laugh at. Maybe around Christmas.
^ permalink raw reply
* [PATCH] powerpc: fix warning when compiling immap_qe.h
From: Timur Tabi @ 2010-10-14 20:15 UTC (permalink / raw)
To: linuxppc-dev, kumar.gala
Fix the warnings genereted by arch/powerpc/include/asm/immap_qe.h when
CONFIG_PHYS_ADDR_T_64BIT is defined:
immap_qe.h: In function 'immrbar_virt_to_phys':
immap_qe.h:472:8: warning: cast from pointer to integer of different size
immap_qe.h:472:24: warning: cast from pointer to integer of different size
immap_qe.h:473:5: warning: cast from pointer to integer of different size
immap_qe.h:473:21: warning: cast from pointer to integer of different size
immap_qe.h:474:36: warning: cast from pointer to integer of different size
Note that the QE does not support 36-bit physical addresses, so even when
CONFIG_PHYS_ADDR_T_64BIT is defined, the QE MURAM must be located below the
4GB boundary.
Signed-off-by: Timur Tabi <timur@freescale.com>
---
arch/powerpc/include/asm/immap_qe.h | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_qe.h b/arch/powerpc/include/asm/immap_qe.h
index 4e10f50..0edb684 100644
--- a/arch/powerpc/include/asm/immap_qe.h
+++ b/arch/powerpc/include/asm/immap_qe.h
@@ -467,13 +467,22 @@ struct qe_immap {
extern struct qe_immap __iomem *qe_immr;
extern phys_addr_t get_qe_base(void);
-static inline unsigned long immrbar_virt_to_phys(void *address)
+/*
+ * Returns the offset within the QE address space of the given pointer.
+ *
+ * Note that the QE does not support 36-bit physical addresses, so if
+ * get_qe_base() returns a number above 4GB, the caller will probably fail.
+ */
+static inline phys_addr_t immrbar_virt_to_phys(void *address)
{
- if ( ((u32)address >= (u32)qe_immr) &&
- ((u32)address < ((u32)qe_immr + QE_IMMAP_SIZE)) )
- return (unsigned long)(address - (u32)qe_immr +
- (u32)get_qe_base());
- return (unsigned long)virt_to_phys(address);
+ void *q = (void *)qe_immr;
+
+ /* Is it a MURAM address? */
+ if ((address >= q) && (address < (q + QE_IMMAP_SIZE)))
+ return get_qe_base() + (address - q);
+
+ /* It's an address returned by kmalloc */
+ return virt_to_phys(address);
}
#endif /* __KERNEL__ */
--
1.7.2.3
^ permalink raw reply related
* Possible kernel stack overflow due to fast interrupts
From: Rick Tao @ 2010-10-14 20:45 UTC (permalink / raw)
To: linuxppc-dev
Hi, all,
I am looking at the kernel source of 2.6.32. It appears to me that kernel stack can be easily getting overflowed in case of fast interrupts. Here is my observation, any comments? Thanks,
Let's assume task A triggers the fast interrupts, and task B was running when the fast interrupt occur.
In the context of task B (according to entry_32.S)
0. Assume task B's ksp = X
1. the interrupt causes exception, allocate exception frame space from
the task B'stack (ksp = X - INT_FRAME_SIZE).
2. interrupt handler is invoked
3. ret_from_except, and resume_kernel is invoked
4. then preempt_schedule_irq is called, which in trun, __schedule() and
context_switch is called. Assume it switches to task A.
In this step,
task B's stack is pushed another INT_FRAME_SIZE to save its context,
so task B's ksp = X - 2 * INT_FRAME_SIZE now.
In the context of task A
a. NIP would point to the instruction after switch_to().
b. MSR_EE is enabled in the call trace (finish_task_switch -->finish_lock_switch-->spin_unlock_irq)
c. do something that would trigger an interrupt later on (such as timer)
d. call schedule() for context switch to task B.
In this step,
task B's stack is popped INT_FRAME_SIZE size for context restore.
Note that task B's ksp = X - INT_FRAME_SIZE
In the context of task B again
a1. similar to step "a" above
b1. similar to step "b" above
c1. interrupt occurs, go to step "1" above, and repeat!!!
As you can see, task B's kernel stack space is reduced by INT_FRAME_SIZE
on each loop. It will eventually overflow.
Thanks for your input.
Rick
^ permalink raw reply
* Re: Oops while running systemtap on the p6 machine against the kernel version 2.6.36-rc7-git3
From: Frank Ch. Eigler @ 2010-10-14 20:46 UTC (permalink / raw)
To: divya; +Cc: linuxppc-dev, systemtap
In-Reply-To: <4CB704AC.4070203@linux.vnet.ibm.com>
divya <dipraksh@linux.vnet.ibm.com> writes:
> While running systemtap tests on the p6 machine , against the kernel
> version 2.6.36-rc7-git3 Oops occured , here are the call trace
Did the oops happen during a systemtap module startup vs. operation
vs. shutdown? stap -V version string?
> BUG: spinlock bad magic on CPU#6, stapio/20398
> -- 0:conmux-control -- time-stamp -- Oct/13/10 2:49:18 --res
> lock: c000000000fcfa18, .magic: 00000000, .owner:<none>/-1, .owner_cpu: 0
> Call Trace:
> [c0000001effbfab0] [c000000000011934] .show_stack+0x6c/0x16c (unreliable)
> [c0000001effbfb60] [c0000000002c9274] .spin_bug+0xb0/0xd4
> [c0000001effbfbf0] [c0000000002c953c] .do_raw_spin_lock+0x48/0x184
> [c0000001effbfc90] [c00000000054af78] ._raw_spin_lock+0x10/0x24
> [c0000001effbfd00] [d000000003015908] .__stp_time_timer_callback+0x94/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [...]
> kernel BUG at kernel/timer.c:681!
> Oops: Exception in kernel mode, sig: 5 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> [...]
> [c0000001effbfc50] [c0000001effbfd00] 0xc0000001effbfd00 (unreliable)
> [c0000001effbfd00] [d00000000301597c] .__stp_time_timer_callback+0x108/0x13c [stap_75ce6f84d34f8665c9a6b8e27fb9ea95_818798]
> [c0000001effbfdc0] [c00000000009c2f8] .run_timer_softirq+0x1d8/0x2a8
We have had occasional problems in the past with something like this:
http://sourceware.org/PR10651, but it never was tracked down to a
systemtap bug per se, as opposed to suspicions that the kernel was not
satisfying one of its guarantees w.r.t. del_timer_sync().
- FChE
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox