Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG

2011-07-07 Thread Michael Neuling 
In message 4e1543b6.9060...@linux.vnet.ibm.com you wrote:
 Hi ,
 
 Problem Description:
 Firmware update using the update_flash -ffilename  results to soft lockup
 BUG
 FLASH: preparing saved firmware image for flash
 FLASH: flash image is 50141296 bytes
 FLASH: performing flash and reboot
 FLASH: this will take several minutes.  Do not power off!
 BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
 
 Steps to reproduce:
 1. Check the firmware information on the machine (using ASM or lsmcode)
 2. Update the system firmware with the update_flash command
 update_flash -f 01FL350_039_038.img
 info: Temporary side will be updated with a newer or
 identical image
 
 Projected Flash Update Results:
 Current T Image: FL350_039
 Current P Image: FL350_039
 New T Image: FL350_039
 New P Image: FL350_039
 Flash image ready...rebooting the system...
 
 Broadcast message from root@abc
 (/dev/hvc0) at 5:25 ...
 
 The system is going down for reboot NOW!
 [root@abc /]# Stopping rhsmcertd[  OK  ]
 Stopping atd: [  OK  ]
 Stopping cups: [  OK  ]
 Stopping abrt daemon: [  OK  ]
 Stopping sshd: [  OK  ]
 Shutting down postfix: [  OK  ]
 Stopping rtas_errd (platform error handling) daemon: [  OK  ]
 Stopping crond: [  OK  ]
 Stopping automount: [  OK  ]
 Stopping HAL daemon: [  OK  ]
 Stopping iprdump: [  OK  ]
 Killing mdmonitor: [  OK  ]]
 Stopping system message bus: [  OK  ]
 Stopping rpcbind: [  OK  ]
 Stopping auditd: [  OK  ]
 Shutting down interface eth0:  [  OK  ]
 Shutting down loopback interface:  [  OK  ]
 ip6tables: Flushing firewall rules: [  OK  ]
 ip6tables: Setting chains to policy ACCEPT: filter [  OK  ]
 ip6tables: Unloading modules: [  OK  ]
 iptables: Flushing firewall rules: [  OK  ]
 iptables: Setting chains to policy ACCEPT: filter [  OK  ]
 iptables: Unloading modules: [  OK  ]
 Sending all processes the TERM signal... [  OK  ]
 Sending all processes the KILL signal... [  OK  ]
 Saving random seed:  [  OK  ]
 Turning off swap:  [  OK  ]
 Turning off quotas:  [  OK  ]
 Unmounting pipe file systems:  [  OK  ]
 Unmounting file systems:  [  OK  ]
 init: Re-executing /sbin/init
 Please stand by while rebooting the system...
 Restarting system.
 FLASH: preparing saved firmware image for flash
 FLASH: flash image is 50141296 bytes
 FLASH: performing flash and reboot
 FLASH: this will take several minutes.  Do not power off!
 BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
 
 This is solved by the following patch

Can you please explain how it fixes it?

Also you need a signed off by.

 
 --- arch/powerpc/kernel/setup-common.c.orig   2011-07-01 22:41:12.952507971 -
0400
 +++ arch/powerpc/kernel/setup-common.c2011-07-01 22:48:31.182507915 -
0400
 @@ -109,11 +109,12 @@ void machine_shutdown(void)
   void machine_restart(char *cmd)
   {
   machine_shutdown();
 - if (ppc_md.restart)
 - ppc_md.restart(cmd);
   #ifdef CONFIG_SMP
 - smp_send_stop();
 +smp_send_stop();

Random white space change here.

   #endif
 + if (ppc_md.restart)
 + ppc_md.restart(cmd);
 + 
   printk(KERN_EMERG System Halted, OK to turn off power\n);
   local_irq_disable();
   while (1) ;
 
 Thanks
 Divya
 
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG

2011-07-07 Thread divya 

On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote:

In message4e1543b6.9060...@linux.vnet.ibm.com  you wrote:
   

Hi ,

Problem Description:
Firmware update using the update_flash -ffilename   results to soft lockup
BUG
FLASH: preparing saved firmware image for flash
FLASH: flash image is 50141296 bytes
FLASH: performing flash and reboot
FLASH: this will take several minutes.  Do not power off!
BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]

Steps to reproduce:
1. Check the firmware information on the machine (using ASM or lsmcode)
2. Update the system firmware with the update_flash command
update_flash -f 01FL350_039_038.img
info: Temporary side will be updated with a newer or
identical image

Projected Flash Update Results:
Current T Image: FL350_039
Current P Image: FL350_039
New T Image: FL350_039
New P Image: FL350_039
Flash image ready...rebooting the system...

Broadcast message from root@abc
(/dev/hvc0) at 5:25 ...

The system is going down for reboot NOW!
[root@abc /]# Stopping rhsmcertd[  OK  ]
Stopping atd: [  OK  ]
Stopping cups: [  OK  ]
Stopping abrt daemon: [  OK  ]
Stopping sshd: [  OK  ]
Shutting down postfix: [  OK  ]
Stopping rtas_errd (platform error handling) daemon: [  OK  ]
Stopping crond: [  OK  ]
Stopping automount: [  OK  ]
Stopping HAL daemon: [  OK  ]
Stopping iprdump: [  OK  ]
Killing mdmonitor: [  OK  ]]
Stopping system message bus: [  OK  ]
Stopping rpcbind: [  OK  ]
Stopping auditd: [  OK  ]
Shutting down interface eth0:  [  OK  ]
Shutting down loopback interface:  [  OK  ]
ip6tables: Flushing firewall rules: [  OK  ]
ip6tables: Setting chains to policy ACCEPT: filter [  OK  ]
ip6tables: Unloading modules: [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Setting chains to policy ACCEPT: filter [  OK  ]
iptables: Unloading modules: [  OK  ]
Sending all processes the TERM signal... [  OK  ]
Sending all processes the KILL signal... [  OK  ]
Saving random seed:  [  OK  ]
Turning off swap:  [  OK  ]
Turning off quotas:  [  OK  ]
Unmounting pipe file systems:  [  OK  ]
Unmounting file systems:  [  OK  ]
init: Re-executing /sbin/init
Please stand by while rebooting the system...
Restarting system.
FLASH: preparing saved firmware image for flash
FLASH: flash image is 50141296 bytes
FLASH: performing flash and reboot
FLASH: this will take several minutes.  Do not power off!
BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]

This is solved by the following patch
 

Can you please explain how it fixes it?
   

Here goes the explanation for the fix.

The flash update is conducted with an RTAS call. The RTAS calls are serialized
by lock_rtas() which uses a spin_lock.

Now there is rtasd which keeps scanning for the RTAS events generated on the
machine. This is performed via workqueue mechanism. The rtas_event_scan() also
uses an RTAS call to scan the events, eventually taking the lock_rtas() before
it issues the request.

The flash update is an operation which takes long time, and hence while we are
at it, anyboy else who wants to make an RTAS call will have to wait until the
update is completed. Now in this case, the rtas_event_scan() is being kicked in
to check for events and it waits a long time on the spin_lock, getting us a
SOFT Lockup.

Before the rtas firmware update starts, all other CPUs should be stopped. Which
means no other CPU should be in lock_rtas(). We do not want other CPUs execute
while FW update is in progress and the system will be rebooted anyway after the
update.



Also you need a signed off by.

Signed-off-by: Divya  dipra...@linux.vnet.ibm.com  
mailto:dipra...@linux.vnet.ibm.com

   

--- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 -
 

0400
   

+++ arch/powerpc/kernel/setup-common.c  2011-07-01 22:48:31.182507915 -
 

0400
   

@@ -109,11 +109,12 @@ void machine_shutdown(void)
   void machine_restart(char *cmd)
   {
machine_shutdown();
-   if (ppc_md.restart)
-   ppc_md.restart(cmd);
   #ifdef CONFIG_SMP
-   smp_send_stop();
+smp_send_stop();
 

Random white space change here.

   

   #endif
+   if (ppc_md.restart)
+   ppc_md.restart(cmd);
+   
printk(KERN_EMERG System Halted, OK to turn off power\n);
local_irq_disable();
while (1) ;

Thanks
Divya

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

 


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.

2011-07-07 Thread Felix Radensky 
On P1022DS both ethernet controllers are connected to RGMII PHYs
accessible via MDIO bus. Remove fixed-link property from ethernet
nodes as they only required when fixed link PHYs without MDIO bus
are used.

Signed-off-by: Felix Radensky fe...@embedded-sol.com
---
 arch/powerpc/boot/dts/p1022ds.dts |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/p1022ds.dts 
b/arch/powerpc/boot/dts/p1022ds.dts
index 98d9426..1be9743 100644
--- a/arch/powerpc/boot/dts/p1022ds.dts
+++ b/arch/powerpc/boot/dts/p1022ds.dts
@@ -412,7 +412,6 @@
fsl,magic-packet;
fsl,wake-on-filer;
local-mac-address = [ 00 00 00 00 00 00 ];
-   fixed-link = 1 1 1000 0 0;
phy-handle = phy0;
phy-connection-type = rgmii-id;
queue-group@0{
@@ -439,7 +438,6 @@
fsl,num_rx_queues = 0x8;
fsl,num_tx_queues = 0x8;
local-mac-address = [ 00 00 00 00 00 00 ];
-   fixed-link = 1 1 1000 0 0;
phy-handle = phy1;
phy-connection-type = rgmii-id;
queue-group@0{
-- 
1.7.4.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

RE: [PATCH 4/4] powerpc: Enable lockup and hung task detectors in pseriesand ppc64 defeconfigs

2011-07-07 Thread David Laight 
 
 As a result of changes to Kconfig files, we no longer enable
 the lockup and hung task detectors. Both are very light weight
 and provide useful information in the event of a hang, so
 reenable them.
...
 +CONFIG_LOCKUP_DETECTOR=y
 +CONFIG_DETECT_HUNG_TASK=y

Is one of thise responsible for generating a kernel stack traceback
when a process has been sleeping uninterruptably for a 'long' time?

We have a kernel subsystem that has several 'worker' threads,
these always sleep uninterruptable (they are shut down by explicit
request) and, at times, can be idle for long periods.

Perhaps it should be possible to disable the check either on
a per-process of per sleep basis?

David


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982

2011-07-07 Thread Mahesh J Salgaonkar 
Hi,

linux-3.0-rc fails to boot on a power7 system with 1TB ram and 896 CPUs.
While the initial boot log shows a soft-lockup [1], the machine is hung after.
Dropping into xmon shows the cpus are all struck at:

cpu 0xa: Vector: 100 (System Reset) at [c00fae51fae0]
pc: c00596b8: .plpar_hcall_norets+0x80/0xd0
lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c00fae51fd60
   msr: 80089032
  current = 0xc00fae49d990
  paca= 0xcebb1900
pid   = 0, comm = kworker/0:1
cpu 0x41: Vector: 100 (System Reset) at [c00fac01bae0]
pc: c00596b8: .plpar_hcall_norets+0x80/0xd0
lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c00fac01bd60
   msr: 80089032
  current = 0xc00faefbf210
  paca= 0xcebba280
pid   = 0, comm = kworker/0:1
cpu 0x21: Vector: 100 (System Reset) at [c00fae9abae0]
pc: c00596b8: .plpar_hcall_norets+0x80/0xd0
lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c00fae9abd60
   msr: 80089032
  current = 0xc00fae998590
  paca= 0xcebb5280
pid   = 0, comm = kworker/0:1
cpu 0xb8: Vector: 100 (System Reset) at [c00fab3dbae0]
pc: c00596b8: .plpar_hcall_norets+0x80/0xd0
lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210
sp: c00fab3dbd60
   msr: 80089032
  current = 0xc00fab3a2710
  paca= 0xcebccc00
pid   = 0, comm = kworker/0:1
..
..
And shows same for all the CPUs.
a:mon t
[link register   ] c005b9a4 .pseries_dedicated_idle_sleep+0x194/0x210
[c00fae51fd60] 134d (unreliable)
[c00fae51fe20] c0018b64 .cpu_idle+0x164/0x210
[c00fae51fed0] c05d55b0 .start_secondary+0x348/0x354
[c00fae51ff90] c0009268 .start_secondary_prolog+0x10/0x14
a:mon S
msr  = 80001032  sprg0= 
pvr  = 003f0201  sprg1= cebb1900
dec  = 30fb5b4f  sprg2= cebb1900
sp   = c00fae51f440  sprg3= 000a
toc  = c0e21f90  dar  = c11aee0c20e8
a:mon


2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
sched: Change NODE sched_domain group creation as the cause.

Thanks,
-Mahesh.

[1]:
POWER7 performance monitor hardware support registered
Brought up 896 CPUs
Enabling Asymmetric SMT scheduling
BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
Modules linked in:
NIP: c0074b90 LR: c008a1c4 CTR: 
REGS: c00fae25f9c0 TRAP: 0901   Not tainted  (3.0.0-rc6)
MSR: 80009032 EE,ME,IR,DR  CR: 2488  XER: 0004
TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0
GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00
GPR04: 0100 0100 c11adcf23418 
GPR08:  c08b2b7d4480 c07b2b35ef80 24ac
GPR12: 4442 cebb
NIP [c0074b90] .update_group_power+0x50/0x190
LR [c008a1c4] .build_sched_domains+0x434/0x490
Call Trace:
[c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable)
[c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490
[c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224
[c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc
[c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70
Instruction dump:
f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054
e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982

2011-07-07 Thread Peter Zijlstra 
On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote:
 
 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
 sched: Change NODE sched_domain group creation as the cause.

Weird, there's no locking anywhere around there. The typical problems
with this patch-set were massive explosions due to bad pointers etc..
But not silent hangs.

The code its stuck at:

 [1]:
 POWER7 performance monitor hardware support registered
 Brought up 896 CPUs
 Enabling Asymmetric SMT scheduling
 BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
 Modules linked in:
 NIP: c0074b90 LR: c008a1c4 CTR: 
 REGS: c00fae25f9c0 TRAP: 0901   Not tainted  (3.0.0-rc6)
 MSR: 80009032 EE,ME,IR,DR  CR: 2488  XER: 0004
 TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0
 GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00
 GPR04: 0100 0100 c11adcf23418 
 GPR08:  c08b2b7d4480 c07b2b35ef80 24ac
 GPR12: 4442 cebb
 NIP [c0074b90] .update_group_power+0x50/0x190
 LR [c008a1c4] .build_sched_domains+0x434/0x490
 Call Trace:
 [c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable)
 [c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490
 [c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224
 [c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc
 [c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70
 Instruction dump:
 f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054
 e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14

doesn't contains any locks, its simply looping over all the cpus, and
with that many I can imagine it takes a while, but getting 'stuck' there
is unexpected to say the least.

Surely this isn't the first multi-node P7 to boot a kernel with this
patch? If my git foo is any good it hit -next on 23rd of May.

I guess I'm asking is, do smaller P7 machines boot? And if so, is there
any difference except size?

How many nodes does the thing have anyway, 28? Hmm, that could mean its
the first machine with 16 nodes to boot this, which would make it
trigger the magic ALL_NODES crap.

Let me dig around there.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982

2011-07-07 Thread Mahesh J Salgaonkar 
On 2011-07-07 12:59:35 Thu, Peter Zijlstra wrote:
 On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote:
  
  2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae -
  sched: Change NODE sched_domain group creation as the cause.
 
 Weird, there's no locking anywhere around there. The typical problems
 with this patch-set were massive explosions due to bad pointers etc..
 But not silent hangs.
 
 The code its stuck at:
 
  [1]:
  POWER7 performance monitor hardware support registered
  Brought up 896 CPUs
  Enabling Asymmetric SMT scheduling
  BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1]
  Modules linked in:
  NIP: c0074b90 LR: c008a1c4 CTR: 
  REGS: c00fae25f9c0 TRAP: 0901   Not tainted  (3.0.0-rc6)
  MSR: 80009032 EE,ME,IR,DR  CR: 2488  XER: 0004
  TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0
  GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00
  GPR04: 0100 0100 c11adcf23418 
  GPR08:  c08b2b7d4480 c07b2b35ef80 24ac
  GPR12: 4442 cebb
  NIP [c0074b90] .update_group_power+0x50/0x190
  LR [c008a1c4] .build_sched_domains+0x434/0x490
  Call Trace:
  [c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable)
  [c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490
  [c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224
  [c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc
  [c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70
  Instruction dump:
  f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054
  e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14
 
 doesn't contains any locks, its simply looping over all the cpus, and
 with that many I can imagine it takes a while, but getting 'stuck' there
 is unexpected to say the least.
 
 Surely this isn't the first multi-node P7 to boot a kernel with this
 patch? If my git foo is any good it hit -next on 23rd of May.
 
 I guess I'm asking is, do smaller P7 machines boot? And if so, is there
 any difference except size?

Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots
fine with 3.0.0-rc.

 
 How many nodes does the thing have anyway, 28? Hmm, that could mean its
 the first machine with 16 nodes to boot this, which would make it
 trigger the magic ALL_NODES crap.

The P7 machine where kernel fails to boot shows following demsg log w.r.t
node map:
---
Zone PFN ranges:
  DMA  0x - 0x01229000
  Normal   empty
Movable zone start PFN for each node
early_node_map[12] active PFN ranges
0: 0x - 0x000fd000
4: 0x000fd000 - 0x002fb000
5: 0x002fb000 - 0x004b9000
6: 0x004b9000 - 0x006b9000
8: 0x006b9000 - 0x007b5000
   12: 0x007b5000 - 0x008b5000
   16: 0x008b5000 - 0x009b1000
   20: 0x009b1000 - 0x00bb1000
   21: 0x00bb1000 - 0x00db1000
   22: 0x00db1000 - 0x00fb1000
   23: 0x00fb1000 - 0x011b1000
   28: 0x011b1000 - 0x01229000
Could not find start_pfn for node 1
Could not find start_pfn for node 2
Could not find start_pfn for node 3
Could not find start_pfn for node 7
Could not find start_pfn for node 9
Could not find start_pfn for node 10
Could not find start_pfn for node 11
Could not find start_pfn for node 13
Could not find start_pfn for node 14
Could not find start_pfn for node 15
Could not find start_pfn for node 17
Could not find start_pfn for node 18
Could not find start_pfn for node 19
Could not find start_pfn for node 29
Could not find start_pfn for node 30
Could not find start_pfn for node 31
[boot]0015 Setup Done
PERCPU: Embedded 1 pages/cpu @c00013c0 s31488 r0 d34048 u65536
Built 28 zonelists in Node order, mobility grouping on.  Total pages:
19026032
Policy zone: DMA
Kernel command line: root=/dev/mapper/vg_nish1-lv_root ro
rd_LVM_LV=vg_nish1/lv_root rd_LVM_LV=VolGroup/lv_swap
rd_LVM_LV=vg_nish1/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=hvc0i memblock=debug 
PID hash table entries: 4096 (order: -1, 32768 bytes)
freeing bootmem node 0
freeing bootmem node 4
freeing bootmem node 5
freeing bootmem node 6
freeing bootmem node 8
freeing bootmem node 12
freeing bootmem node 16
freeing bootmem node 20
freeing bootmem node 21
freeing bootmem node 22
freeing bootmem node 23
freeing bootmem node 28
Memory: 1213775296k/1218707456k available (13312k kernel code, 4932160k
reserved, 1600k data, 2727k bss, 4928k init)
---

Thanks,
-Mahesh.

 
 Let me dig around there.
 ___
 Linuxppc-dev mailing list
 Linuxppc-dev@lists.ozlabs.org
 https://lists.ozlabs.org/listinfo/linuxppc-dev

-- 
Mahesh J Salgaonkar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org

Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982

2011-07-07 Thread Peter Zijlstra 
On Thu, 2011-07-07 at 17:25 +0530, Mahesh J Salgaonkar wrote:
  I guess I'm asking is, do smaller P7 machines boot? And if so, is there
  any difference except size?
 
 Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots
 fine with 3.0.0-rc. 

That sounds like a single node machine. P7 comes as {4,6,8}*4 (16,24,32
cpus) per socket. And that 2G doesn't sound like much either.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes

2011-07-07 Thread Anatolij Gustschin 
We use both MSCAN controllers on this board, so do not disable
them in the device tree.

Signed-off-by: Anatolij Gustschin ag...@denx.de
---
 arch/powerpc/boot/dts/digsy_mtc.dts |8 
 1 files changed, 0 insertions(+), 8 deletions(-)

diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts 
b/arch/powerpc/boot/dts/digsy_mtc.dts
index 2aad7ae..a7511f2 100644
--- a/arch/powerpc/boot/dts/digsy_mtc.dts
+++ b/arch/powerpc/boot/dts/digsy_mtc.dts
@@ -37,14 +37,6 @@
status = disabled;
};
 
-   can@900 {
-   status = disabled;
-   };
-
-   can@980 {
-   status = disabled;
-   };
-
spi@f00 {
msp430@0 {
compatible = spidev;
-- 
1.7.1

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Kumar Gala 

On Jul 1, 2011, at 5:09 PM, Greg KH wrote:

 On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
 On some architectures we need to setup pdev_archdata before we add the
 device.  Waiting til a bus_notifier is too late since we might need the
 pdev_archdata in the bus notifier.  One example is setting up of dma_mask
 pointers such that it can be used in a bus_notifier.
 
 We add noop version of arch_setup_pdev_archdata() in
 asm-generic/platform_device.h and allow the arch code to override with
 access the full definitions of struct device, struct platform_device, and
 struct pdev_archdata.
 
 Isn't there some way to use weak symbols to keep us from having to
 create this .h file in every single arch and then if the arch wants to
 define it, it does so?
 
 That should make this patch simpler, right?
 
 thanks,
 
 greg k-h

Changing to weak should be doable if we are ok with the additional function 
call always happening.

- k

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor

2011-07-07 Thread Laurentiu TUDOR 
mpc85xx_smp_init platform init function assumed that smp_ops.message_pass
was set to default arch dependent smp_muxed_ipi_message_pass.
However this does not seem to happen. Moreover, the arch specific code
in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so
calls the default implementation.

Signed-off-by: Laurentiu TUDOR laurentiu.tu...@freescale.com
---
 arch/powerpc/platforms/85xx/smp.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/platforms/85xx/smp.c 
b/arch/powerpc/platforms/85xx/smp.c
index f5aa619..5b9b901 100644
--- a/arch/powerpc/platforms/85xx/smp.c
+++ b/arch/powerpc/platforms/85xx/smp.c
@@ -2,7 +2,7 @@
  * Author: Andy Fleming aflem...@freescale.com
  *Kumar Gala ga...@kernel.crashing.org
  *
- * Copyright 2006-2008 Freescale Semiconductor Inc.
+ * Copyright 2006-2008, 2011 Freescale Semiconductor Inc.
  *
  * 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
@@ -239,12 +239,13 @@ void __init mpc85xx_smp_init(void)
}
 
if (cpu_has_feature(CPU_FTR_DBELL)) {
-   /* .message_pass defaults to smp_muxed_ipi_message_pass */
+   /*
+* If left NULL, .message_pass defaults to
+* smp_muxed_ipi_message_pass
+*/
smp_85xx_ops.cause_ipi = doorbell_cause_ipi;
}
 
-   BUG_ON(!smp_85xx_ops.message_pass);
-
smp_ops = smp_85xx_ops;
 
 #ifdef CONFIG_KEXEC
-- 
1.6.6


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Greg KH 
On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote:
 
 On Jul 1, 2011, at 5:09 PM, Greg KH wrote:
 
  On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
  On some architectures we need to setup pdev_archdata before we add the
  device.  Waiting til a bus_notifier is too late since we might need the
  pdev_archdata in the bus notifier.  One example is setting up of dma_mask
  pointers such that it can be used in a bus_notifier.
  
  We add noop version of arch_setup_pdev_archdata() in
  asm-generic/platform_device.h and allow the arch code to override with
  access the full definitions of struct device, struct platform_device, and
  struct pdev_archdata.
  
  Isn't there some way to use weak symbols to keep us from having to
  create this .h file in every single arch and then if the arch wants to
  define it, it does so?
  
  That should make this patch simpler, right?
  
  thanks,
  
  greg k-h
 
 Changing to weak should be doable if we are ok with the additional
 function call always happening.

Given that this is not a fast path, and the function call for the
normal case would do nothing, it should be fine, right?

greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Analysing a kernel panic

2011-07-07 Thread Guillaume Dargaud 
I'll expand a bit on my previous message. Here's a more detailed dump of what 
happens when my system receives a second 
interrupt (the 1st one works fine) from my hardware:

[  263.586996] do_IRQ: stack overflow: 1920
[  263.590785] Call Trace:
[  263.593275] [c7792780] [c00073ac] show_stack+0x80/0x19c (unreliable)
[  263.599543] [c77927c0] [c0004d98] do_IRQ+0x48/0xcc
[  263.604314] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[  263.609714] [c7792890] [] (null)
[  263.613628] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.619476] [c7792960] [] (null)
[  263.623410] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[  263.629090] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[  263.633852] [c7792990] [c000f434] ret_from_except+0x0/0x18
[  263.639262] [c7792a50] [] (null)
[  263.643176] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.649025] [c7792b20] [] (null)
[  263.652945] [c7792b30] [c0052554] handle_level_irq+0x54/0x128
[  263.658638] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc
[  263.663400] [c7792b50] [c000f434] ret_from_except+0x0/0x18
[  263.668811] [c7792c10] [] (null)
[  263.672725] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.678574] [c7792ce0] [] (null)
[  263.682494] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128
[  263.688189] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc
[  263.692949] [c7792d10] [c000f434] ret_from_except+0x0/0x18
[  263.698360] [c7792dd0] [] (null)
[  263.702274] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.708123] [c7792ea0] [] (null)
[  263.712043] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128
[  263.717736] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc
[  263.722498] [c7792ed0] [c000f434] ret_from_except+0x0/0x18
[  263.727909] [c7792f90] [] (null)
[  263.731822] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.737671] [c7793060] [] (null)
[  263.741592] [c7793070] [c0052554] handle_level_irq+0x54/0x128
[  263.747285] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc
[  263.752048] [c7793090] [c000f434] ret_from_except+0x0/0x18
[  263.757457] [c7793150] [] (null)
[  263.761372] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.767221] [c7793220] [] (null)
[  263.771143] [c7793230] [c0052554] handle_level_irq+0x54/0x128
[  263.776834] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc
[  263.781597] [c7793250] [c000f434] ret_from_except+0x0/0x18
[  263.787006] [c7793310] [] (null)
[  263.790921] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.796770] [c77933e0] [] (null)
[  263.800693] [c77933f0] [c0052554] handle_level_irq+0x54/0x128
[  263.806383] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc
[  263.811146] [c7793410] [c000f434] ret_from_except+0x0/0x18
[  263.816555] [c77934d0] [] (null)
[  263.820470] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.826319] [c77935a0] [] (null)
[  263.830241] [c77935b0] [c0052554] handle_level_irq+0x54/0x128
[  263.835932] [c77935c0] [c0004dd8] do_IRQ+0x88/0xcc
[  263.840694] [c77935d0] [c000f434] ret_from_except+0x0/0x18
[  263.846104] [c7793690] [] (null)
[  263.850019] [c77936a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.855867] [c7793760] [] (null)
[  263.859788] [c7793770] [c0052554] handle_level_irq+0x54/0x128
[  263.865481] [c7793780] [c0004dd8] do_IRQ+0x88/0xcc
[  263.870242] [c7793790] [c000f434] ret_from_except+0x0/0x18
[  263.875653] [c7793850] [] (null)
[  263.879567] [c7793860] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.885416] [c7793920] [] (null)
[  263.889336] [c7793930] [c0052554] handle_level_irq+0x54/0x128
[  263.895030] [c7793940] [c0004dd8] do_IRQ+0x88/0xcc
[  263.899790] [c7793950] [c000f434] ret_from_except+0x0/0x18
[  263.905201] [c7793a10] [] (null)
[  263.909115] [c7793a20] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.914971] do_IRQ: stack overflow: 1472
[  263.918843] Call Trace:
[  263.921304] [c77925c0] [c00073ac] show_stack+0x80/0x19c (unreliable)
[  263.927600] [c7792600] [c0004d98] do_IRQ+0x48/0xcc
[  263.932357] [c7792610] [c000f434] ret_from_except+0x0/0x18
[  263.937791] [c77926d0] [3b9aca00] 0x3b9aca00
[  263.942035] [c77926e0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.947899] [c77927a0] [3b9aca00] 0x3b9aca00
[  263.952151] [c77927b0] [c0052554] handle_level_irq+0x54/0x128
[  263.957842] [c77927c0] [c0004dd8] do_IRQ+0x88/0xcc
[  263.962603] [c77927d0] [c000f434] ret_from_except+0x0/0x18
[  263.968014] [c7792890] [] (null)
[  263.971928] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c
[  263.97] [c7792960] [] (null)
[  263.981697] [c7792970] [c0052554] handle_level_irq+0x54/0x128
[  263.987390] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc
[  263.992152] [c7792990] [c000f434] ret_from_except+0x0/0x18
[  263.997563] [c7792a50] [] (null)
[  264.001476] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c
[  264.007326] [c7792b20] [] (null)

Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.

2011-07-07 Thread Timur Tabi 
Felix Radensky wrote:
 On P1022DS both ethernet controllers are connected to RGMII PHYs
 accessible via MDIO bus. Remove fixed-link property from ethernet
 nodes as they only required when fixed link PHYs without MDIO bus
 are used.
 
 Signed-off-by: Felix Radensky fe...@embedded-sol.com

Acked-by: Timur Tabi ti...@freescale.com

Ethernet works before and after applying this patch, so all I can say is that it
doesn't break anything.

-- 
Timur Tabi
Linux kernel developer at Freescale

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] powerpc,ppc4xx_edac: Add comma to fix build error

2011-07-07 Thread Mike Williams 
Commit 4018294b53d1dae026880e45f174c1cc63b5d435 broke the ppc4xx_edac driver at
line 210 where the struct member is missing a comma.

Signed-off-by: Mike Williams m...@mikebwilliams.com
---
 drivers/edac/ppc4xx_edac.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c
index b9f0c20..446b5c0 100644
--- a/drivers/edac/ppc4xx_edac.c
+++ b/drivers/edac/ppc4xx_edac.c
@@ -206,7 +206,7 @@ static struct of_platform_driver ppc4xx_edac_driver = {
.remove = ppc4xx_edac_remove,
.driver = {
.owner = THIS_MODULE,
-   .name = PPC4XX_EDAC_MODULE_NAME
+   .name = PPC4XX_EDAC_MODULE_NAME,
.of_match_table = ppc4xx_edac_match,
},
 };
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH] drivers/video: use strings to specify the Freescale DIU monitor port

2011-07-07 Thread Timur Tabi 
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow
the user to specify the port by name (dvi, lvds, or dlvds).  This works
on the kernel command line, the module command-line, and the sysfs monitor
device.

Note that changing the monitor port does not currently work on the P1022DS,
because the code that talks to the PIXIS FPGA is broken.

Signed-off-by: Timur Tabi ti...@freescale.com
---
 arch/powerpc/platforms/512x/mpc512x_shared.c |   22 +++-
 arch/powerpc/platforms/85xx/p1022_ds.c   |   47 -
 arch/powerpc/platforms/86xx/mpc8610_hpcd.c   |   55 +---
 arch/powerpc/sysdev/fsl_soc.h|   25 ++---
 drivers/video/fsl-diu-fb.c   |   73 +++--
 5 files changed, 128 insertions(+), 94 deletions(-)

diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c 
b/arch/powerpc/platforms/512x/mpc512x_shared.c
index e41ebbd..3dc62f9 100644
--- a/arch/powerpc/platforms/512x/mpc512x_shared.c
+++ b/arch/powerpc/platforms/512x/mpc512x_shared.c
@@ -66,8 +66,8 @@ struct fsl_diu_shared_fb {
boolin_use;
 };
 
-unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel,
- int monitor_port)
+u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port,
+unsigned int bits_per_pixel)
 {
switch (bits_per_pixel) {
case 32:
@@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int 
bits_per_pixel,
return 0x0400;
 }
 
-void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base)
+void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port,
+char *gamma_table_base)
 {
 }
 
-void mpc512x_set_monitor_port(int monitor_port)
+void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port)
 {
 }
 
@@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock)
iounmap(ccm);
 }
 
-ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf)
+enum fsl_diu_monitor_port
+mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port)
 {
-   return sprintf(buf, 0 - 5121 LCD\n);
-}
-
-int mpc512x_set_sysfs_monitor_port(int val)
-{
-   return 0;
+   return FSL_DIU_PORT_DVI;
 }
 
 static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb;
@@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void)
diu_ops.set_gamma_table = mpc512x_set_gamma_table;
diu_ops.set_monitor_port= mpc512x_set_monitor_port;
diu_ops.set_pixel_clock = mpc512x_set_pixel_clock;
-   diu_ops.show_monitor_port   = mpc512x_show_monitor_port;
-   diu_ops.set_sysfs_monitor_port  = mpc512x_set_sysfs_monitor_port;
+   diu_ops.valid_monitor_port  = mpc512x_valid_monitor_port;
diu_ops.release_bootmem = mpc512x_release_bootmem;
 #endif
 }
diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c 
b/arch/powerpc/platforms/85xx/p1022_ds.c
index 266b3aa..c01c727 100644
--- a/arch/powerpc/platforms/85xx/p1022_ds.c
+++ b/arch/powerpc/platforms/85xx/p1022_ds.c
@@ -93,8 +93,8 @@
  * The Area Descriptor is a 32-bit value that determine which bits in each
  * pixel are to be used for each color.
  */
-static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel,
-   int monitor_port)
+static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port,
+   unsigned int bits_per_pixel)
 {
switch (bits_per_pixel) {
case 32:
@@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int 
bits_per_pixel,
  * On some boards, the gamma table for some ports may need to be modified.
  * This is not the case on the P1022DS, so we do nothing.
 */
-static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base)
+static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port,
+   char *gamma_table_base)
 {
 }
 
@@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char 
*gamma_table_base)
  * p1022ds_set_monitor_port: switch the output to a different monitor port
  *
  */
-static void p1022ds_set_monitor_port(int monitor_port)
+static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port)
 {
struct device_node *pixis_node;
void __iomem *pixis;
@@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port)
}
brdcfg1 = pixis + 9;/* BRDCFG1 is at offset 9 in the ngPIXIS */
 
-   switch (monitor_port) {
-   case 0: /* DVI */
+   switch (port) {
+   case FSL_DIU_PORT_DVI:
+   printk(KERN_INFO %s:%u\n, __func__, __LINE__);
/* Enable the DVI port, disable the DFP and the backlight */
clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT,
 PX_BRDCFG1_DVIEN);
break;
-   case 1: /* Single link LVDS */
+

Re: [PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes

2011-07-07 Thread Grant Likely 
On Thu, Jul 07, 2011 at 02:49:50PM +0200, Anatolij Gustschin wrote:
 We use both MSCAN controllers on this board, so do not disable
 them in the device tree.
 
 Signed-off-by: Anatolij Gustschin ag...@denx.de

Applied, thanks.

g.

 ---
  arch/powerpc/boot/dts/digsy_mtc.dts |8 
  1 files changed, 0 insertions(+), 8 deletions(-)
 
 diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts 
 b/arch/powerpc/boot/dts/digsy_mtc.dts
 index 2aad7ae..a7511f2 100644
 --- a/arch/powerpc/boot/dts/digsy_mtc.dts
 +++ b/arch/powerpc/boot/dts/digsy_mtc.dts
 @@ -37,14 +37,6 @@
   status = disabled;
   };
  
 - can@900 {
 - status = disabled;
 - };
 -
 - can@980 {
 - status = disabled;
 - };
 -
   spi@f00 {
   msp430@0 {
   compatible = spidev;
 -- 
 1.7.1
 
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc: enable access to HT Host-Bridge on Maple

2011-07-07 Thread Benjamin Herrenschmidt 
On Fri, 2011-07-01 at 18:44 +0200, Segher Boessenkool wrote:
  CPC925/CPC945 use special window to access host bridge  
  functionality of
  u3-ht. Provide a way to access this device.
 
 Why?  Is anything going to use it?
 
  +static int u3_ht_root_read_config(struct pci_controller *hose, u8  
  offset,
  + int len, u32 *val)
  +{
  +   volatile void __iomem *addr;
  +
  +   addr = hose-cfg_addr;
  +   addr += ((offset  ~3)  2) + (4 - len - (offset  3));
 
 This will only work for len 1,2,4 with offset a multiple of len, is that
 guaranteed here?

I think the upper layer does. Dbl check tho.

  hose-cfg_data = ioremap(0xf200, 0x0200);
  +   hose-cfg_addr = ioremap(0xf807, 0x1000);
 
 Eww.  You could just make a global instead of abusing existing fields,
 there can be only one CPC9x5 in a system anyway.

Nah, that's fine, we abuse it that way regulary :-)

Cheers,
Ben.


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Analysing a kernel panic

2011-07-07 Thread Benjamin Herrenschmidt 
On Tue, 2011-07-05 at 16:19 +0200, Guillaume Dargaud wrote:
 Hello all,
 one of my drivers is causing a kernel panic and I _think_ it happens in the 
 1st call to the interrupt routine.
 What kind of information can I extract from the following ?
 Is it like a core dump that I can load with the executable in the debugger to 
 know exactly what happened (I doubt it) ?


 Kernel stack overflow in process c6ce80a0, r1=c778c070

That's bad...

 NIP: c000d270 LR: c000f3c8 CTR: c0017fd0
 REGS: c778bfc0 TRAP: 0501   Tainted: G  D (2.6.34)
 MSR: 00029030 EE,ME,CE,IR,DR  CR: 2448  XER: 
 TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000
 GPR00: 00029030 c778c070 c6ce80a0 c778c090 0800 32d8 0001 0001
 GPR08: 32da  00021032 c000d110 06ce82a8
 NIP [c000d270] program_check_exception+0x160/0x228
 LR [c000f3c8] ret_from_except_full+0x0/0x4c
 Call Trace:
 Instruction dump:
 38090004 901f0080 48d8 3ca3 7fe4fb78 80df0080 60a50001 3865
 48a8 7ca6 60008000 7c000124 77c00c04 41a20068 4bffef89 2f83fff2
 Kernel panic - not syncing: kernel stack overflow
 Call Trace:
 Rebooting in 180 seconds..
 
 My driver is xad.ko, though /dev/xps-acqui-data. The user program is SoftNoy.
 The code for the ISR (note that this code works fine on the same driver for a 
 slightly different piece of custom 
 hardware):
 
 static irqreturn_t XadIsr(int irq, void *dev_id) {
   Xad.control_reg-fin_in = 0;
   Xad.interrupt_reg-ISR  = 1;
   Xad.interrupt_IPIF_reg-ISR = 4;
 
   Xad.control_reg-flux_address[0] = BUFFER_PHY_BASE + BUF_SZ*(++Xad.Icnt 
 % BUF_NB); 
   Xad.control_reg-flux_address[1] = Xad.control_reg-flux_address[0] + 
 BUF_SZ/2;
 
   if (Xad.IcntXad.Rcnt+BUF_NB) 
   Xad.control_reg-flux_start=255;// Arm the next 
 interrupt
   else {
   // There aren't any buffers available for the next read. We'll 
 do the start in the read routine
   Xad.Suspended=1;
   Xad.OverflowsSinceLastRead++;
   Xad.Overflow++;
   DBG_ADD_CHAR('*');
   if (Verbose) printk(KERN_WARNING SD %dth buffer overflow: 
 %d-%d=%d=%d\n FL, 
   Xad.Overflow, Xad.Icnt, Xad.Rcnt, Xad.Icnt-Xad.Rcnt, 
 BUF_NB);
   }
 
   wake_up_interruptible(Xad.wait);
   return IRQ_HANDLED;
 }
 
What is Xad. ? (btw, coding style FAIL !)

Are you trying to write to HW registers using a structure like that
without using the appropriate MMIO register accessors ?

In that case, your accesses may happen our of order since you don't have
memory barriers (among other potential problems).

The crash looks like you aren't properly clearing the interrupt
condition on the HW, it remains asserted, tho it shouldn't overflow like
that, something seems wrong with your PIC.

What HW is this ? What PIC ? It looks like the interrupt source isn't
masked on the PIC itself while it's being handled or something...

Cheers,
Ben.

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

powerpc endian issue

2011-07-07 Thread Yuan Shi (yuansshi) 
Hello,

I am using perf to collect data from powerpc and analyze the data on a
local server. 

When I am trying to use perf report the error fatal:imcompatible file
format comes up. It is noticed that the error is generated due to
perf_header size dismatch.

The issue is caused by that the powerpc is big endian and local server
is little endian. 

I am wondering if any of you have ideas how to solve this problem.
Basically, how to analyze the perf.data generated on a powerpc on a
little endian Machine.

 

 

Sincerely yours,

Yuan

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG

2011-07-07 Thread Michael Neuling 
In message 4e155f15.1030...@linux.vnet.ibm.com you wrote:
 This is a multi-part message in MIME format.
 --===3790206687486290502==
 Content-Type: multipart/alternative;
  boundary=080309090408040507080807
 
 This is a multi-part message in MIME format.
 --080309090408040507080807
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 
 On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote:
  In message4e1543b6.9060...@linux.vnet.ibm.com  you wrote:
 
  Hi ,
 
  Problem Description:
  Firmware update using the update_flash -ffilename   results to soft lock
up
  BUG
  FLASH: preparing saved firmware image for flash
  FLASH: flash image is 50141296 bytes
  FLASH: performing flash and reboot
  FLASH: this will take several minutes.  Do not power off!
  BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
 
  Steps to reproduce:
  1. Check the firmware information on the machine (using ASM or lsmcode)
  2. Update the system firmware with the update_flash command
  update_flash -f 01FL350_039_038.img
  info: Temporary side will be updated with a newer or
  identical image
 
  Projected Flash Update Results:
  Current T Image: FL350_039
  Current P Image: FL350_039
  New T Image: FL350_039
  New P Image: FL350_039
  Flash image ready...rebooting the system...
 
  Broadcast message from root@abc
  (/dev/hvc0) at 5:25 ...
 
  The system is going down for reboot NOW!
  [root@abc /]# Stopping rhsmcertd[  OK  ]
  Stopping atd: [  OK  ]
  Stopping cups: [  OK  ]
  Stopping abrt daemon: [  OK  ]
  Stopping sshd: [  OK  ]
  Shutting down postfix: [  OK  ]
  Stopping rtas_errd (platform error handling) daemon: [  OK  ]
  Stopping crond: [  OK  ]
  Stopping automount: [  OK  ]
  Stopping HAL daemon: [  OK  ]
  Stopping iprdump: [  OK  ]
  Killing mdmonitor: [  OK  ]]
  Stopping system message bus: [  OK  ]
  Stopping rpcbind: [  OK  ]
  Stopping auditd: [  OK  ]
  Shutting down interface eth0:  [  OK  ]
  Shutting down loopback interface:  [  OK  ]
  ip6tables: Flushing firewall rules: [  OK  ]
  ip6tables: Setting chains to policy ACCEPT: filter [  OK  ]
  ip6tables: Unloading modules: [  OK  ]
  iptables: Flushing firewall rules: [  OK  ]
  iptables: Setting chains to policy ACCEPT: filter [  OK  ]
  iptables: Unloading modules: [  OK  ]
  Sending all processes the TERM signal... [  OK  ]
  Sending all processes the KILL signal... [  OK  ]
  Saving random seed:  [  OK  ]
  Turning off swap:  [  OK  ]
  Turning off quotas:  [  OK  ]
  Unmounting pipe file systems:  [  OK  ]
  Unmounting file systems:  [  OK  ]
  init: Re-executing /sbin/init
  Please stand by while rebooting the system...
  Restarting system.
  FLASH: preparing saved firmware image for flash
  FLASH: flash image is 50141296 bytes
  FLASH: performing flash and reboot
  FLASH: this will take several minutes.  Do not power off!
  BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36]
 
  This is solved by the following patch
   
  Can you please explain how it fixes it?
 
 The flash update is conducted with an RTAS call. The RTAS calls are
 serialized by lock_rtas() which uses a spin_lock.
 
 Now there is rtasd which keeps scanning for the RTAS events generated
 on the machine. This is performed via workqueue mechanism. The
 rtas_event_scan() also uses an RTAS call to scan the events,
 eventually taking the lock_rtas() before it issues the request.

 The flash update is an operation which takes long time, and hence
 while we are at it, anyboy else who wants to make an RTAS call will
 have to wait until the update is completed. Now in this case, the
 rtas_event_scan() is being kicked in to check for events and it waits
 a long time on the spin_lock, getting us a SOFT Lockup.

What other RTAS calls are going on at this point?  It worries me we are
stopping a CPU that's doing RTAS calls.  Your solution would seem to be
papering over a more serious problem.

 Before the rtas firmware update starts, all other CPUs should be
 stopped. Which means no other CPU should be in lock_rtas(). We do not
 want other CPUs execute while FW update is in progress and the system
 will be rebooted anyway after the update.

Mikey
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Kumar Gala 
On some architectures we need to setup pdev_archdata before we add the
device.  Waiting til a bus_notifier is too late since we might need the
pdev_archdata in the bus notifier.  One example is setting up of dma_mask
pointers such that it can be used in a bus_notifier.

We add weak noop version of arch_setup_pdev_archdata() and allow the arch
code to override with access the full definitions of struct device,
struct platform_device, and struct pdev_archdata.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
v4:
* Move to use a weak function based on comments from Greg
v3:
* Add more comments and add missing call to arch_setup_pdev_archdata in
  platform_device_register
v2:
* Added license, and comments about arch_setup_pdev_archdata()
  per Mike's comments

 drivers/base/platform.c |   22 ++
 include/linux/platform_device.h |1 +
 2 files changed, 23 insertions(+), 0 deletions(-)

diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 1c291af..060686d 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -32,6 +32,26 @@ struct device platform_bus = {
 EXPORT_SYMBOL_GPL(platform_bus);
 
 /**
+ * arch_setup_pdev_archdata - Allow manipulation of archdata before its used
+ * @dev: platform device
+ *
+ * This is called before platform_device_add() such that any pdev_archdata may
+ * be setup before the platform_notifier is called.  So if a user needs to
+ * manipulate any relevant information in the pdev_archdata they can do:
+ *
+ * platform_devic_alloc()
+ * ... manipulate ...
+ * platform_device_add()
+ *
+ * And if they don't care they can just call platform_device_register() and
+ * everything will just work out.
+ */
+void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
+{
+   return ;
+}
+
+/**
  * platform_get_resource - get a resource for a device
  * @dev: platform device
  * @type: resource type
@@ -173,6 +193,7 @@ struct platform_device *platform_device_alloc(const char 
*name, int id)
pa-pdev.id = id;
device_initialize(pa-pdev.dev);
pa-pdev.dev.release = platform_device_release;
+   arch_setup_pdev_archdata(pa-pdev);
}
 
return pa ? pa-pdev : NULL;
@@ -334,6 +355,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
 int platform_device_register(struct platform_device *pdev)
 {
device_initialize(pdev-dev);
+   arch_setup_pdev_archdata(pdev);
return platform_device_add(pdev);
 }
 EXPORT_SYMBOL_GPL(platform_device_register);
diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
index ede1a80..27bb05a 100644
--- a/include/linux/platform_device.h
+++ b/include/linux/platform_device.h
@@ -42,6 +42,7 @@ extern void platform_device_unregister(struct platform_device 
*);
 extern struct bus_type platform_bus_type;
 extern struct device platform_bus;
 
+extern void arch_setup_pdev_archdata(struct platform_device *);
 extern struct resource *platform_get_resource(struct platform_device *, 
unsigned int, unsigned int);
 extern int platform_get_irq(struct platform_device *, unsigned int);
 extern struct resource *platform_get_resource_byname(struct platform_device *, 
unsigned int, const char *);
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 2/3] powerpc: implement arch_setup_pdev_archdata

2011-07-07 Thread Kumar Gala 
We have a long standing issues with platform devices not have a valid
dma_mask pointer.  This hasn't been an issue to date as no platform
device has tried to set its dma_mask value to a non-default value.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/kernel/setup-common.c |   28 
 drivers/of/platform.c  |4 ++--
 2 files changed, 6 insertions(+), 26 deletions(-)

diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 79fca26..ea82baa 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -704,29 +704,9 @@ static int powerpc_debugfs_init(void)
 arch_initcall(powerpc_debugfs_init);
 #endif
 
-static int ppc_dflt_bus_notify(struct notifier_block *nb,
-   unsigned long action, void *data)
+void arch_setup_pdev_archdata(struct platform_device *pdev)
 {
-   struct device *dev = data;
-
-   /* We are only intereted in device addition */
-   if (action != BUS_NOTIFY_ADD_DEVICE)
-   return 0;
-
-   set_dma_ops(dev, dma_direct_ops);
-
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block ppc_dflt_plat_bus_notifier = {
-   .notifier_call = ppc_dflt_bus_notify,
-   .priority = INT_MAX,
-};
-
-static int __init setup_bus_notifier(void)
-{
-   bus_register_notifier(platform_bus_type, ppc_dflt_plat_bus_notifier);
-   return 0;
+   pdev-archdata.dma_mask = DMA_BIT_MASK(32);
+   pdev-dev.dma_mask = pdev-archdata.dma_mask;
+   set_dma_ops(pdev-dev, dma_direct_ops);
 }
-
-arch_initcall(setup_bus_notifier);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 63d3cb7..cfc6a79 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -153,7 +153,7 @@ struct platform_device *of_device_alloc(struct device_node 
*np,
}
 
dev-dev.of_node = of_node_get(np);
-#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE)
+#if defined(CONFIG_MICROBLAZE)
dev-dev.dma_mask = dev-archdata.dma_mask;
 #endif
dev-dev.parent = parent;
@@ -189,7 +189,7 @@ struct platform_device *of_platform_device_create(struct 
device_node *np,
if (!dev)
return NULL;
 
-#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE)
+#if defined(CONFIG_MICROBLAZE)
dev-archdata.dma_mask = 0xUL;
 #endif
dev-dev.coherent_dma_mask = DMA_BIT_MASK(32);
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

[PATCH v4 3/3] powerpc: Dont require a dma_ops struct to set dma mask

2011-07-07 Thread Kumar Gala 
The only reason to require a dma_ops struct is to see if it has
implemented set_dma_mask.  If not we can fall back to setting the mask
directly.

This resolves an issue with how to sequence the setting of a DMA mask
for platform devices.  Before we had an issue in that we have no way of
setting the DMA mask before the various low level bus notifiers get
called that might check it (swiotlb).

So now we can do:

pdev = platform_device_alloc(foobar, 0);
dma_set_mask(pdev-dev, DMA_BIT_MASK(37));
platform_device_add(pdev);

And expect the right thing to happen with the bus notifiers get called
via platform_device_add.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 arch/powerpc/kernel/dma.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index d238c08..4f0959f 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -161,9 +161,7 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
 
if (ppc_md.dma_set_mask)
return ppc_md.dma_set_mask(dev, dma_mask);
-   if (unlikely(dma_ops == NULL))
-   return -EIO;
-   if (dma_ops-set_dma_mask != NULL)
+   if ((dma_ops != NULL)  (dma_ops-set_dma_mask != NULL))
return dma_ops-set_dma_mask(dev, dma_mask);
if (!dev-dma_mask || !dma_supported(dev, dma_mask))
return -EIO;
-- 
1.7.3.4

___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Kumar Gala 

On Jul 7, 2011, at 9:11 AM, Greg KH wrote:

 On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote:
 
 On Jul 1, 2011, at 5:09 PM, Greg KH wrote:
 
 On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote:
 On some architectures we need to setup pdev_archdata before we add the
 device.  Waiting til a bus_notifier is too late since we might need the
 pdev_archdata in the bus notifier.  One example is setting up of dma_mask
 pointers such that it can be used in a bus_notifier.
 
 We add noop version of arch_setup_pdev_archdata() in
 asm-generic/platform_device.h and allow the arch code to override with
 access the full definitions of struct device, struct platform_device, and
 struct pdev_archdata.
 
 Isn't there some way to use weak symbols to keep us from having to
 create this .h file in every single arch and then if the arch wants to
 define it, it does so?
 
 That should make this patch simpler, right?
 
 thanks,
 
 greg k-h
 
 Changing to weak should be doable if we are ok with the additional
 function call always happening.
 
 Given that this is not a fast path, and the function call for the
 normal case would do nothing, it should be fine, right?
 
 greg k-h

Sounds good, new version sent that uses weak instead.  If this looks good let 
me know if you just want to ACK and send via powerpc.git tree or if you'll pick 
these up.

- k


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor

2011-07-07 Thread Kumar Gala 

On Jul 7, 2011, at 8:44 AM, Laurentiu TUDOR wrote:

 mpc85xx_smp_init platform init function assumed that smp_ops.message_pass
 was set to default arch dependent smp_muxed_ipi_message_pass.
 However this does not seem to happen. Moreover, the arch specific code
 in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so
 calls the default implementation.
 
 Signed-off-by: Laurentiu TUDOR laurentiu.tu...@freescale.com
 ---
 arch/powerpc/platforms/85xx/smp.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

Re-worded commit message a bit, applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.

2011-07-07 Thread Kumar Gala 

On Jul 7, 2011, at 2:37 AM, Felix Radensky wrote:

 On P1022DS both ethernet controllers are connected to RGMII PHYs
 accessible via MDIO bus. Remove fixed-link property from ethernet
 nodes as they only required when fixed link PHYs without MDIO bus
 are used.
 
 Signed-off-by: Felix Radensky fe...@embedded-sol.com
 ---
 arch/powerpc/boot/dts/p1022ds.dts |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

applied to next
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH] powerpc/85xx: Add p2040 RDB board support

2011-07-07 Thread Kumar Gala 

On Jun 28, 2011, at 2:52 AM, Mingkai Hu wrote:

 P2040RDB Specification:
 ---
 2Gbyte unbuffered DDR3 SDRAM SO-DIMM(64bit bus)
 128 Mbyte NOR flash single-chip memory
 256 Kbit M24256 I2C EEPROM
 16 Mbyte SPI memory
 SD connector to interface with the SD memory card
 dTSEC1: connected to the Vitesse SGMII PHY (VSC8221)
 dTSEC2: connected to the Vitesse SGMII PHY (VSC8221)
 dTSEC3: connected to the Vitesse SGMII PHY (VSC8221)
 dTSEC4: connected to the Vitesse RGMII PHY (VSC8641)
 dTSEC5: connected to the Vitesse RGMII PHY (VSC8641)
 I2C1: Real time clock, Temperature sensor
 I2C2: Vcore Regulator, 256Kbit I2C Bus EEPROM
 SATA: Lanes C and Land D of Bank2 are connected to two SATA connectors
 UART: supports two UARTs up to 115200 bps for console
 USB 2.0: connected via a internal UTMI PHY to two TYPE-A interfaces
 PCIe:
 - Lanes E, F, G and H of Bank1 are connected to one x4 PCIe SLOT1
 - Lanes C and Land D of Bank2 are connected to one x4 PCIe SLOT2
 
 Signed-off-by: Mingkai Hu mingkai...@freescale.com
 ---
 Based on http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git
 
 arch/powerpc/boot/dts/p2040rdb.dts   |  166 +++
 arch/powerpc/boot/dts/p2040si.dtsi   |  623 ++
 arch/powerpc/configs/corenet32_smp_defconfig |1 +
 arch/powerpc/platforms/85xx/Kconfig  |   12 +
 arch/powerpc/platforms/85xx/Makefile |1 +
 arch/powerpc/platforms/85xx/p2040_rdb.c  |   88 
 6 files changed, 891 insertions(+), 0 deletions(-)
 create mode 100644 arch/powerpc/boot/dts/p2040rdb.dts
 create mode 100644 arch/powerpc/boot/dts/p2040si.dtsi
 create mode 100644 arch/powerpc/platforms/85xx/p2040_rdb.c

applied to next

- k


___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH 4/5] powerpc: Create next_tlbcam_idx percpu variable for FSL_BOOKE

2011-07-07 Thread Kumar Gala 

On Jun 28, 2011, at 2:54 PM, Becky Bruce wrote:

 From: Becky Bruce bec...@kernel.crashing.org
 
 This is used to round-robin TLBCAM entries.
 
 Signed-off-by: Becky Bruce bec...@kernel.crashing.org
 ---
 arch/powerpc/include/asm/mmu.h |5 +
 arch/powerpc/kernel/smp.c  |4 
 arch/powerpc/mm/mem.c  |9 +
 arch/powerpc/mm/tlb_nohash.c   |6 ++
 4 files changed, 24 insertions(+), 0 deletions(-)

applied to next

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Greg KH 
On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote:
 On some architectures we need to setup pdev_archdata before we add the
 device.  Waiting til a bus_notifier is too late since we might need the
 pdev_archdata in the bus notifier.  One example is setting up of dma_mask
 pointers such that it can be used in a bus_notifier.
 
 We add weak noop version of arch_setup_pdev_archdata() and allow the arch
 code to override with access the full definitions of struct device,
 struct platform_device, and struct pdev_archdata.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 v4:
 * Move to use a weak function based on comments from Greg
 v3:
 * Add more comments and add missing call to arch_setup_pdev_archdata in
   platform_device_register
 v2:
 * Added license, and comments about arch_setup_pdev_archdata()
   per Mike's comments
 
  drivers/base/platform.c |   22 ++
  include/linux/platform_device.h |1 +
  2 files changed, 23 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/base/platform.c b/drivers/base/platform.c
 index 1c291af..060686d 100644
 --- a/drivers/base/platform.c
 +++ b/drivers/base/platform.c
 @@ -32,6 +32,26 @@ struct device platform_bus = {
  EXPORT_SYMBOL_GPL(platform_bus);
  
  /**
 + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used
 + * @dev: platform device
 + *
 + * This is called before platform_device_add() such that any pdev_archdata 
 may
 + * be setup before the platform_notifier is called.  So if a user needs to
 + * manipulate any relevant information in the pdev_archdata they can do:
 + *
 + *   platform_devic_alloc()
 + *   ... manipulate ...
 + *   platform_device_add()
 + *
 + * And if they don't care they can just call platform_device_register() and
 + * everything will just work out.
 + */
 +void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
 +{
 + return ;
 +}

The return isn't needed, nor is the extra ' ' there, right?  :)

Change that and you can take this through the ppc tree and add a:
Acked-by: Greg Kroah-Hartman
to them.

thanks,

greg k-h
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata

2011-07-07 Thread Kumar Gala 

On Jul 7, 2011, at 11:22 PM, Greg KH wrote:

 On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote:
 On some architectures we need to setup pdev_archdata before we add the
 device.  Waiting til a bus_notifier is too late since we might need the
 pdev_archdata in the bus notifier.  One example is setting up of dma_mask
 pointers such that it can be used in a bus_notifier.
 
 We add weak noop version of arch_setup_pdev_archdata() and allow the arch
 code to override with access the full definitions of struct device,
 struct platform_device, and struct pdev_archdata.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---
 v4:
 * Move to use a weak function based on comments from Greg
 v3:
 * Add more comments and add missing call to arch_setup_pdev_archdata in
  platform_device_register
 v2:
 * Added license, and comments about arch_setup_pdev_archdata()
  per Mike's comments
 
 drivers/base/platform.c |   22 ++
 include/linux/platform_device.h |1 +
 2 files changed, 23 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/base/platform.c b/drivers/base/platform.c
 index 1c291af..060686d 100644
 --- a/drivers/base/platform.c
 +++ b/drivers/base/platform.c
 @@ -32,6 +32,26 @@ struct device platform_bus = {
 EXPORT_SYMBOL_GPL(platform_bus);
 
 /**
 + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used
 + * @dev: platform device
 + *
 + * This is called before platform_device_add() such that any pdev_archdata 
 may
 + * be setup before the platform_notifier is called.  So if a user needs to
 + * manipulate any relevant information in the pdev_archdata they can do:
 + *
 + *  platform_devic_alloc()
 + *  ... manipulate ...
 + *  platform_device_add()
 + *
 + * And if they don't care they can just call platform_device_register() and
 + * everything will just work out.
 + */
 +void __weak arch_setup_pdev_archdata(struct platform_device *pdev)
 +{
 +return ;
 +}
 
 The return isn't needed, nor is the extra ' ' there, right?  :)

yep, removed the ';' as well ;)

 Change that and you can take this through the ppc tree and add a:
   Acked-by: Greg Kroah-Hartman
 to them.

Ack added to all.

thanks

- k
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev