Re: Re: Build regressions/improvements in v3.4-rc7

2012-05-18 Thread Michael Ellerman
On Thu, 2012-05-17 at 13:42 -0500, Timur Tabi wrote:
 Benjamin Herrenschmidt wrote:
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'enum
  fsl_diu_monitor_port' declared inside parameter list [-Werror]:  =
  70:9, 84:9, 88:36
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: 'return' with
  a value, in function returning void [-Werror]:  = 189:2
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: function
  declaration isn't a prototype [-Werror=strict-prototypes]:  = 69:5,
  88:6, 83:6, 187:1
+ arch/powerpc/platforms/512x/mpc512x_shared.c: error: its scope is
  only this definition or declaration, which is probably not what you
  want [-Werror]:  = 70:9
 
 So I think I have a fix for these, but I still would like the actual
 .config so that I can be sure.

I believe it's this one:

http://kisskb.ellerman.id.au/kisskb/buildresult/6312867/config/


cheers



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


Re: [PATCH] mtd: Fix typo in Kconfig

2012-05-18 Thread Artem Bityutskiy
On Thu, 2012-05-17 at 22:43 +0200, Frank Svendsboe wrote:
 MTD_OF_PARTS and the default setting is not working due to using 'Y'
 instead of 'y', introduced in commit
 d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
 possibly other boards using DTS defined partitions and not having
 CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root
 after v3.1.

The commit was released in v3.2, so it not v3.1 probably?

 Signed-off-by: Frank Svendsboe frank.svends...@gmail.com

I've amended the subject to make it look scarier than just a fix of a
typo, added a tag for the stable tree, and pushed to l2-mtd.git, thanks!

commit aa2465b2d5d44defb269ac66a2d2b6e6b8feb399
Author: Frank Svendsboe frank.svends...@gmail.com
Date:   Thu May 17 22:43:09 2012 +0200

mtd: of_parts: fix breakage in Kconfig

MTD_OF_PARTS and the default setting is not working due to using 'Y'
instead of 'y', introduced in commit
d6137badeff1ef64b4e0092ec249ebdeaeb3ff37. This made our board, and
possibly other boards using DTS defined partitions and not having
CONFIG_MTD_OF_PARTS=y defined in the defconfig, fail to mount root.

Signed-off-by: Frank Svendsboe frank.svends...@gmail.com
Cc: sta...@kernel.org [3.2+]
Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com

-- 
Best Regards,
Artem Bityutskiy


signature.asc
Description: This is a digitally signed message part
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH powerpc] fix a lockdep complaint in start_secondary

2012-05-18 Thread Deepthi Dharwar
On 05/18/2012 08:24 AM, Li Zhong wrote:

 On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
 On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:

 On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
 This patch tries to fix following lockdep complaints:

  .../...

 pseries_notify_cpu_idle_add_cpu() actually does
 cpuidle_disable_device(), and then cpuidle_enable_device(), which
 releases and allocates the resources respectively. ( Also, all the data
 are cleared and reinitialized after this cycle). The problem here is:
 something like kzalloc(GFP_KERNEL), wait_for_completion() would have
 problems running here where irqs are still disabled. 


 This is true when the system is booting up.


 So yes, it looks definitely fishy. I don't have time to study cpuidle
 today to check whether that's correct or not so I'm CCing Deepthi
 Dharwar who did all that cpuidle work for pseries.

 Deepthi, can you check whether that patch is correct ?


 pseries_notify_cpu_idle_add_cpu() is essential to be called for
 hotplug event. So by removing this call completely wouldn't
 support cpus registering under cpuidle on hotplug and default idle is
 executed on those with do not give much powersavings. 
 
 Maybe I missed that part.. would you please give some details how
 removing this would prevent powersaving cpuidle being called after
 hotplug? 
 
 After rereading the codes, I think ppc_md.power_save() is the one you
 mentioned that could give much powersavings? 
 
 It is registered as pSeries_idle(), which calls cpuidle_idle_call(). 
 It seems to me that it would still be called after hotplug. 
 
 Or maybe I misunderstood your point? 


If cpuidle_idle_call() fails, in case device is not present, off ,
not initialized and not ready to use, default idle is called.
Coming out of a hotplug event, it is good to cleanly exit out
and reallocate all the resources when needed, rather than using the
stale one to make sure this call succeeds always.

Default idle executed in pSeries_idle() :
HMT_low();
HMT_very_low();
This would not have much powersavings.

CPUIDLE subsystem needs to be informed when a hot plug event occurs
and not a good practice to mask this subsystem from this system wide
event.

I agree that putting it in xics setup is not a good thing.
Notifier would be a cleaner way of doing it.
That way, duplication of resources allocated and released at boot
time is not done.


 
 Ideal way it to
 have a notifier in pseries backend driver for hotplug notification and
 then remove this function from here.
 I am currently working on this patch, will post it out soon.


 Actually, cpuidle_enable_device() is called for each possible cpu when
 the driver is registered. So I don't think the resources needed to be
 released and allocated each time cpu becomes online. Something like
 cpuidle_reset_device() would be enough to clear and reinitialize the
 data.

 However, after some studying of the data to be cleared, I think it's
 also reasonable to keep the previous data. For example: 

 /sys/devices/system/cpu/cpu#/cpuidle/state#/usage 
 the number of times this idle state has been entered
 /sys/devices/system/cpu/cpu#/cpuidle/state#/time
 the amount of time spent in this idle state

 So I think we could just remove the function call doing the
 disable/enable cycle:

 Please correct me if I missed anything.


 If removed, this would not handle cpu hotplug events for cpuidle.



 Reported-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
 Tested-by: Paul E. McKenney paul...@linux.vnet.ibm.com
 ---
  arch/powerpc/platforms/pseries/smp.c |1 -
  1 files changed, 0 insertions(+), 1 deletions(-)

 diff --git a/arch/powerpc/platforms/pseries/smp.c
 b/arch/powerpc/platforms/pseries/smp.c
 index e16bb8d..71706bc 100644
 --- a/arch/powerpc/platforms/pseries/smp.c
 +++ b/arch/powerpc/platforms/pseries/smp.c
 @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
  #endif
 -  pseries_notify_cpuidle_add_cpu(cpu);
  }
  
  static int __devinit smp_pSeries_kick_cpu(int nr)




 Cheers,
 Deepthi
 
 
 


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


Re: [PATCH powerpc] fix a lockdep complaint in start_secondary

2012-05-18 Thread Li Zhong
On Fri, 2012-05-18 at 16:54 +0530, Deepthi Dharwar wrote:
 On 05/18/2012 08:24 AM, Li Zhong wrote:
 
  On Thu, 2012-05-17 at 15:52 +0530, Deepthi Dharwar wrote:
  On 05/17/2012 09:58 AM, Benjamin Herrenschmidt wrote:
 
  On Thu, 2012-05-17 at 12:01 +0800, Li Zhong wrote:
  This patch tries to fix following lockdep complaints:
 
   .../...
 
  pseries_notify_cpu_idle_add_cpu() actually does
  cpuidle_disable_device(), and then cpuidle_enable_device(), which
  releases and allocates the resources respectively. ( Also, all the data
  are cleared and reinitialized after this cycle). The problem here is:
  something like kzalloc(GFP_KERNEL), wait_for_completion() would have
  problems running here where irqs are still disabled. 
 
 
  This is true when the system is booting up.
 
 
  So yes, it looks definitely fishy. I don't have time to study cpuidle
  today to check whether that's correct or not so I'm CCing Deepthi
  Dharwar who did all that cpuidle work for pseries.
 
  Deepthi, can you check whether that patch is correct ?
 
 
  pseries_notify_cpu_idle_add_cpu() is essential to be called for
  hotplug event. So by removing this call completely wouldn't
  support cpus registering under cpuidle on hotplug and default idle is
  executed on those with do not give much powersavings. 
  
  Maybe I missed that part.. would you please give some details how
  removing this would prevent powersaving cpuidle being called after
  hotplug? 
  
  After rereading the codes, I think ppc_md.power_save() is the one you
  mentioned that could give much powersavings? 
  
  It is registered as pSeries_idle(), which calls cpuidle_idle_call(). 
  It seems to me that it would still be called after hotplug. 
  
  Or maybe I misunderstood your point? 
 
 
 If cpuidle_idle_call() fails, in case device is not present, off ,
 not initialized and not ready to use, default idle is called.
 Coming out of a hotplug event, it is good to cleanly exit out
 and reallocate all the resources when needed, rather than using the
 stale one to make sure this call succeeds always.
 
 Default idle executed in pSeries_idle() :
   HMT_low();
 HMT_very_low();
 This would not have much powersavings.

From my testing, cpuidle_idle_call didn't fail after hotplug, so it
didn't fall back to the default idling. I still don't see any big
problems if we don't reallocate the resources. 

 
 CPUIDLE subsystem needs to be informed when a hot plug event occurs
 and not a good practice to mask this subsystem from this system wide
 event.

Ok, I agree that the CPUIDLE subsystem should be notified about the hot
plug events. Thank you. 

I think this would be included in your coming patch, and I could just
stop here, hehe

 
 I agree that putting it in xics setup is not a good thing.
 Notifier would be a cleaner way of doing it.
 That way, duplication of resources allocated and released at boot
 time is not done.
   
 
  
  Ideal way it to
  have a notifier in pseries backend driver for hotplug notification and
  then remove this function from here.
  I am currently working on this patch, will post it out soon.
 
 
  Actually, cpuidle_enable_device() is called for each possible cpu when
  the driver is registered. So I don't think the resources needed to be
  released and allocated each time cpu becomes online. Something like
  cpuidle_reset_device() would be enough to clear and reinitialize the
  data.
 
  However, after some studying of the data to be cleared, I think it's
  also reasonable to keep the previous data. For example: 
 
  /sys/devices/system/cpu/cpu#/cpuidle/state#/usage 
  the number of times this idle state has been entered
  /sys/devices/system/cpu/cpu#/cpuidle/state#/time
  the amount of time spent in this idle state
 
  So I think we could just remove the function call doing the
  disable/enable cycle:
 
  Please correct me if I missed anything.
 
 
  If removed, this would not handle cpu hotplug events for cpuidle.
 
 
 
  Reported-by: Paul E. McKenney paul...@linux.vnet.ibm.com
  Signed-off-by: Li Zhong zh...@linux.vnet.ibm.com
  Tested-by: Paul E. McKenney paul...@linux.vnet.ibm.com
  ---
   arch/powerpc/platforms/pseries/smp.c |1 -
   1 files changed, 0 insertions(+), 1 deletions(-)
 
  diff --git a/arch/powerpc/platforms/pseries/smp.c
  b/arch/powerpc/platforms/pseries/smp.c
  index e16bb8d..71706bc 100644
  --- a/arch/powerpc/platforms/pseries/smp.c
  +++ b/arch/powerpc/platforms/pseries/smp.c
  @@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
   set_cpu_current_state(cpu, CPU_STATE_ONLINE);
   set_default_offline_state(cpu);
   #endif
  -pseries_notify_cpuidle_add_cpu(cpu);
   }
   
   static int __devinit smp_pSeries_kick_cpu(int nr)
 
 
 
 
  Cheers,
  Deepthi
  
  
  
 
 


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


[PATCH] cpuidle: (POWER) Replace pseries_notify_cpuidle_add call with a elegant notifier to fix lockdep problem in start_secondary

2012-05-18 Thread Deepthi Dharwar

The following patch is to remove the pseries_notify_add_cpu() call
and replace it by a hot plug notifier.
This would prevent cpuidle resources being
released and allocated each time cpu comes online on pseries.
The earlier design was causing a lockdep problem
in start_secondary as reported on this thread
-https://lkml.org/lkml/2012/5/17/2

This applies on 3.4-rc7

Signed-off-by: Deepthi Dharwar deep...@linux.vnet.ibm.com
---
 arch/powerpc/include/asm/processor.h|2 --
 arch/powerpc/platforms/pseries/processor_idle.c |   25
+--
 arch/powerpc/platforms/pseries/smp.c|1 -
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/include/asm/processor.h
b/arch/powerpc/include/asm/processor.h
index 8e2d037..c6bc22b 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -390,10 +390,8 @@ void cpu_idle_wait(void);

 #ifdef CONFIG_PSERIES_IDLE
 extern void update_smt_snooze_delay(int snooze);
-extern int pseries_notify_cpuidle_add_cpu(int cpu);
 #else
 static inline void update_smt_snooze_delay(int snooze) {}
-static inline int pseries_notify_cpuidle_add_cpu(int cpu) { return 0; }
 #endif

 extern void flush_instruction_cache(void);
diff --git a/arch/powerpc/platforms/pseries/processor_idle.c
b/arch/powerpc/platforms/pseries/processor_idle.c
index 41a34bc..d1a7dc0 100644
--- a/arch/powerpc/platforms/pseries/processor_idle.c
+++ b/arch/powerpc/platforms/pseries/processor_idle.c
@@ -11,6 +11,7 @@
 #include linux/moduleparam.h
 #include linux/cpuidle.h
 #include linux/cpu.h
+#include linux/notifier.h

 #include asm/paca.h
 #include asm/reg.h
@@ -186,17 +187,28 @@ static struct cpuidle_state
shared_states[MAX_IDLE_STATE_COUNT] = {
.enter = shared_cede_loop },
 };

-int pseries_notify_cpuidle_add_cpu(int cpu)
+static int pseries_cpuidle_add_cpu_notifier(struct notifier_block *n,
+   unsigned long action, void *hcpu)
 {
+   int hotcpu = (unsigned long)hcpu;
struct cpuidle_device *dev =
-   per_cpu_ptr(pseries_cpuidle_devices, cpu);
-   if (dev  cpuidle_get_driver()) {
-   cpuidle_disable_device(dev);
-   cpuidle_enable_device(dev);
+   per_cpu_ptr(pseries_cpuidle_devices, hotcpu);
+
+   switch (action  0xf) {
+   case CPU_ONLINE:
+   if (dev  cpuidle_get_driver()) {
+   cpuidle_disable_device(dev);
+   cpuidle_enable_device(dev);
+   }
+   break;
}
-   return 0;
+   return NOTIFY_OK;
 }

+static struct notifier_block setup_hotplug_notifier = {
+   .notifier_call = pseries_cpuidle_add_cpu_notifier,
+};
+
 /*
  * pseries_cpuidle_driver_init()
  */
@@ -321,6 +333,7 @@ static int __init pseries_processor_idle_init(void)
return retval;
}

+   register_cpu_notifier(setup_hotplug_notifier);
printk(KERN_DEBUG pseries_idle_driver registered\n);

return 0;
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index e16bb8d..71706bc 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -147,7 +147,6 @@ static void __devinit smp_xics_setup_cpu(int cpu)
set_cpu_current_state(cpu, CPU_STATE_ONLINE);
set_default_offline_state(cpu);
 #endif
-   pseries_notify_cpuidle_add_cpu(cpu);
 }

 static int __devinit smp_pSeries_kick_cpu(int nr)

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


[PATCH EDAC v26 27/66] pasemi_edac: convert driver to use the new edac ABI

2012-05-18 Thread Mauro Carvalho Chehab
The legacy edac ABI is going to be removed. Port the driver to use
and benefit from the new API functionality.

Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/edac/pasemi_edac.c |   25 -
 1 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/drivers/edac/pasemi_edac.c b/drivers/edac/pasemi_edac.c
index 3fcefda..46aed62 100644
--- a/drivers/edac/pasemi_edac.c
+++ b/drivers/edac/pasemi_edac.c
@@ -110,15 +110,16 @@ static void pasemi_edac_process_error_info(struct 
mem_ctl_info *mci, u32 errsta)
/* uncorrectable/multi-bit errors */
if (errsta  (MCDEBUG_ERRSTA_MBE_STATUS |
  MCDEBUG_ERRSTA_RFL_STATUS)) {
-   edac_mc_handle_ue(mci, mci-csrows[cs].first_page, 0,
- cs, mci-ctl_name);
+   edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
+mci-csrows[cs].first_page, 0, 0,
+cs, 0, -1, mci-ctl_name, , NULL);
}
 
/* correctable/single-bit errors */
-   if (errsta  MCDEBUG_ERRSTA_SBE_STATUS) {
-   edac_mc_handle_ce(mci, mci-csrows[cs].first_page, 0,
- 0, cs, 0, mci-ctl_name);
-   }
+   if (errsta  MCDEBUG_ERRSTA_SBE_STATUS)
+   edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
+mci-csrows[cs].first_page, 0, 0,
+cs, 0, -1, mci-ctl_name, , NULL);
 }
 
 static void pasemi_edac_check(struct mem_ctl_info *mci)
@@ -191,6 +192,7 @@ static int __devinit pasemi_edac_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
 {
struct mem_ctl_info *mci = NULL;
+   struct edac_mc_layer layers[2];
u32 errctl1, errcor, scrub, mcen;
 
pci_read_config_dword(pdev, MCCFG_MCEN, mcen);
@@ -207,9 +209,14 @@ static int __devinit pasemi_edac_probe(struct pci_dev 
*pdev,
MCDEBUG_ERRCTL1_RFL_LOG_EN;
pci_write_config_dword(pdev, MCDEBUG_ERRCTL1, errctl1);
 
-   mci = edac_mc_alloc(0, PASEMI_EDAC_NR_CSROWS, PASEMI_EDAC_NR_CHANS,
-   system_mmc_id++);
-
+   layers[0].type = EDAC_MC_LAYER_CHIP_SELECT;
+   layers[0].size = PASEMI_EDAC_NR_CSROWS;
+   layers[0].is_virt_csrow = true;
+   layers[1].type = EDAC_MC_LAYER_CHANNEL;
+   layers[1].size = PASEMI_EDAC_NR_CHANS;
+   layers[1].is_virt_csrow = false;
+   mci = new_edac_mc_alloc(system_mmc_id++, ARRAY_SIZE(layers), layers,
+   0);
if (mci == NULL)
return -ENOMEM;
 
-- 
1.7.8

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


[PATCH EDAC v26 07/66] edac: Change internal representation to work with layers

2012-05-18 Thread Mauro Carvalho Chehab
Change the EDAC internal representation to work with non-csrow
based memory controllers.

There are lots of those memory controllers nowadays, and more
are coming. So, the EDAC internal representation needs to be
changed, in order to work with those memory controllers, while
preserving backward compatibility with the old ones.

The edac core was written with the idea that memory controllers
are able to directly access csrows.

This is not true for FB-DIMM and RAMBUS memory controllers.

Also, some recent advanced memory controllers don't present a per-csrows
view. Instead, they view memories as DIMMs, instead of ranks.

So, change the allocation and error report routines to allow
them to work with all types of architectures.

This will allow the removal of several hacks with FB-DIMM and RAMBUS
memory controllers.

Also, several tests were done on different platforms using different
x86 drivers.

TODO: a multi-rank DIMMs are currently represented by multiple DIMM
entries in struct dimm_info. That means that changing a label for one
rank won't change the same label for the other ranks at the same DIMM.
This bug is present since the beginning of the EDAC, so it is not a big
deal. However, on several drivers, it is possible to fix this issue, but
it should be a per-driver fix, as the csrow = DIMM arrangement may not
be equal for all. So, don't try to fix it here yet.

I tried to make this patch as short as possible, preceding it with
several other patches that simplified the logic here. Yet, as the
internal API changes, all drivers need changes. The changes are
generally bigger in the drivers for FB-DIMMs.

Cc: Aristeu Rozanski aroza...@redhat.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Chris Metcalf cmetc...@tilera.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/edac/edac_core.h |   99 ++--
 drivers/edac/edac_mc.c   |  702 +-
 include/linux/edac.h |   38 ++-
 3 files changed, 552 insertions(+), 287 deletions(-)

diff --git a/drivers/edac/edac_core.h b/drivers/edac/edac_core.h
index e48ab31..1286c5e 100644
--- a/drivers/edac/edac_core.h
+++ b/drivers/edac/edac_core.h
@@ -447,8 +447,12 @@ static inline void pci_write_bits32(struct pci_dev *pdev, 
int offset,
 
 #endif /* CONFIG_PCI */
 
-extern struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows,
- unsigned nr_chans, int edac_index);
+struct mem_ctl_info *edac_mc_alloc(unsigned sz_pvt, unsigned nr_csrows,
+  unsigned nr_chans, int edac_index);
+struct mem_ctl_info *new_edac_mc_alloc(unsigned edac_index,
+  unsigned n_layers,
+  struct edac_mc_layer *layers,
+  unsigned sz_pvt);
 extern int edac_mc_add_mc(struct mem_ctl_info *mci);
 extern void edac_mc_free(struct mem_ctl_info *mci);
 extern struct mem_ctl_info *edac_mc_find(int idx);
@@ -467,24 +471,78 @@ extern int edac_mc_find_csrow_by_page(struct mem_ctl_info 
*mci,
  * reporting logic and function interface - reduces conditional
  * statement clutter and extra function arguments.
  */
-extern void edac_mc_handle_ce(struct mem_ctl_info *mci,
- unsigned long page_frame_number,
- unsigned long offset_in_page,
- unsigned long syndrome, int row, int channel,
- const char *msg);
-extern void edac_mc_handle_ce_no_info(struct mem_ctl_info *mci,
- const char *msg);
-extern void edac_mc_handle_ue(struct mem_ctl_info *mci,
- unsigned long page_frame_number,
- unsigned long offset_in_page, int row,
- const char *msg);
-extern void edac_mc_handle_ue_no_info(struct mem_ctl_info *mci,
- const char *msg);
-extern void edac_mc_handle_fbd_ue(struct mem_ctl_info *mci, unsigned int csrow,
- unsigned int channel0, unsigned int channel1,
- char *msg);
-extern void 

[PATCH EDAC v26 55/66] edac: change the mem allocation scheme to make Documentation/kobject.txt happy

2012-05-18 Thread Mauro Carvalho Chehab
Kernel kobjects have rigid rules: each container object should be
dynamically allocated, and can't be allocated into a single kmalloc.

EDAC never obeyed this rule: it has a single malloc function that
allocates all needed data into a single kzalloc.

As this is not accepted anymore, change the allocation schema of the
EDAC *_info structs to enforce this Kernel standard.

Acked-by: Chris Metcalf cmetc...@tilera.com
Cc: Aristeu Rozanski aroza...@redhat.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Greg K H gre...@linuxfoundation.org
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Shaohui Xie shaohui@freescale.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/edac/amd64_edac.c  |   10 ++-
 drivers/edac/amd76x_edac.c |8 +-
 drivers/edac/cell_edac.c   |8 +-
 drivers/edac/cpc925_edac.c |8 +-
 drivers/edac/e752x_edac.c  |4 +-
 drivers/edac/e7xxx_edac.c  |4 +-
 drivers/edac/edac_mc.c |  107 ++
 drivers/edac/edac_mc_sysfs.c   |  126 +++-
 drivers/edac/i3000_edac.c  |6 +-
 drivers/edac/i3200_edac.c  |4 +-
 drivers/edac/i5400_edac.c  |6 +-
 drivers/edac/i82443bxgx_edac.c |4 +-
 drivers/edac/i82860_edac.c |6 +-
 drivers/edac/i82875p_edac.c|6 +-
 drivers/edac/i82975x_edac.c|   10 ++--
 drivers/edac/mpc85xx_edac.c|6 +-
 drivers/edac/mv64x60_edac.c|4 +-
 drivers/edac/pasemi_edac.c |8 +-
 drivers/edac/r82600_edac.c |4 +-
 drivers/edac/tile_edac.c   |4 +-
 drivers/edac/x38_edac.c|4 +-
 include/linux/edac.h   |   59 +-
 22 files changed, 242 insertions(+), 164 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 9905834..9fbced7 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2205,6 +2205,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 
dct, int csrow_nr)
 static int init_csrows(struct mem_ctl_info *mci)
 {
struct csrow_info *csrow;
+   struct dimm_info *dimm;
struct amd64_pvt *pvt = mci-pvt_info;
u64 base, mask;
u32 val;
@@ -,7 +2223,7 @@ static int init_csrows(struct mem_ctl_info *mci)
!!(val  NBCFG_CHIPKILL), !!(val  NBCFG_ECC_ENABLE));
 
for_each_chip_select(i, 0, pvt) {
-   csrow = mci-csrows[i];
+   csrow = mci-csrows[i];
 
if (!csrow_enabled(i, 0, pvt)  !csrow_enabled(i, 1, pvt)) {
debugf1(CSROW %d EMPTY for node %d\n, i,
@@ -2257,9 +2258,10 @@ static int init_csrows(struct mem_ctl_info *mci)
edac_mode = EDAC_NONE;
 
for (j = 0; j  pvt-channel_count; j++) {
-   csrow-channels[j].dimm-mtype = mtype;
-   csrow-channels[j].dimm-edac_mode = edac_mode;
-   csrow-channels[j].dimm-nr_pages = nr_pages;
+   dimm = csrow-channels[j]-dimm;
+   dimm-mtype = mtype;
+   dimm-edac_mode = edac_mode;
+   dimm-nr_pages = nr_pages;
}
}
 
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 65e639c..bebdd49 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -146,7 +146,7 @@ static int amd76x_process_error_info(struct mem_ctl_info 
*mci,
if (handle_errors) {
row = (info-ecc_mode_status  4)  0xf;
edac_mc_handle_error(HW_EVENT_ERR_UNCORRECTED, mci,
-mci-csrows[row].first_page, 0, 0,
+mci-csrows[row]-first_page, 0, 0,
 row, 0, -1,
 mci-ctl_name, , NULL);
}
@@ -161,7 +161,7 @@ static int amd76x_process_error_info(struct mem_ctl_info 
*mci,
if (handle_errors) {
row = info-ecc_mode_status  0xf;
edac_mc_handle_error(HW_EVENT_ERR_CORRECTED, mci,
-mci-csrows[row].first_page, 0, 0,
+mci-csrows[row]-first_page, 0, 0,
 row, 0, -1,
 mci-ctl_name, , 

[PATCH EDAC v26 04/66] edac: move nr_pages to dimm struct

2012-05-18 Thread Mauro Carvalho Chehab
The number of pages is a dimm property. Move it to the dimm struct.

After this change, it is possible to add sysfs nodes for the DIMM's that
will properly represent the DIMM stick properties, including its size.

A TODO fix here is to properly represent dual-rank/quad-rank DIMMs when
the memory controller represents the memory via chip select rows.

Reviewed-by: Aristeu Rozanski aroza...@redhat.com
Acked-by: Borislav Petkov borislav.pet...@amd.com
Acked-by: Chris Metcalf cmetc...@tilera.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/edac/amd64_edac.c  |   10 +---
 drivers/edac/amd76x_edac.c |6 ++--
 drivers/edac/cell_edac.c   |8 --
 drivers/edac/cpc925_edac.c |8 --
 drivers/edac/e752x_edac.c  |6 +++-
 drivers/edac/e7xxx_edac.c  |5 ++-
 drivers/edac/edac_mc.c |   16 -
 drivers/edac/edac_mc_sysfs.c   |   47 
 drivers/edac/i3000_edac.c  |6 +++-
 drivers/edac/i3200_edac.c  |3 +-
 drivers/edac/i5000_edac.c  |   14 ++-
 drivers/edac/i5100_edac.c  |   22 +++---
 drivers/edac/i5400_edac.c  |9 ++-
 drivers/edac/i7300_edac.c  |   22 +-
 drivers/edac/i7core_edac.c |   10 ++--
 drivers/edac/i82443bxgx_edac.c |2 +-
 drivers/edac/i82860_edac.c |2 +-
 drivers/edac/i82875p_edac.c|5 ++-
 drivers/edac/i82975x_edac.c|   11 ++--
 drivers/edac/mpc85xx_edac.c|3 +-
 drivers/edac/mv64x60_edac.c|3 +-
 drivers/edac/pasemi_edac.c |   14 ++--
 drivers/edac/ppc4xx_edac.c |5 ++-
 drivers/edac/r82600_edac.c |3 +-
 drivers/edac/sb_edac.c |8 +-
 drivers/edac/tile_edac.c   |2 +-
 drivers/edac/x38_edac.c|4 +-
 include/linux/edac.h   |8 --
 28 files changed, 146 insertions(+), 116 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index e2c5a94..1ceb8e2 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2152,7 +2152,7 @@ static u32 amd64_csrow_nr_pages(struct amd64_pvt *pvt, u8 
dct, int csrow_nr)
nr_pages = pvt-ops-dbam_to_cs(pvt, dct, cs_mode)  (20 - PAGE_SHIFT);
 
debugf0(  (csrow=%d) DBAM map index= %d\n, csrow_nr, cs_mode);
-   debugf0(nr_pages= %u  channel-count = %d\n,
+   debugf0(nr_pages/channel= %u  channel-count = %d\n,
nr_pages, pvt-channel_count);
 
return nr_pages;
@@ -2171,6 +2171,7 @@ static int init_csrows(struct mem_ctl_info *mci)
int i, j, empty = 1;
enum mem_type mtype;
enum edac_type edac_mode;
+   int nr_pages = 0;
 
amd64_read_pci_cfg(pvt-F3, NBCFG, val);
 
@@ -2194,9 +2195,9 @@ static int init_csrows(struct mem_ctl_info *mci)
 
empty = 0;
if (csrow_enabled(i, 0, pvt))
-   csrow-nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
+   nr_pages = amd64_csrow_nr_pages(pvt, 0, i);
if (csrow_enabled(i, 1, pvt))
-   csrow-nr_pages += amd64_csrow_nr_pages(pvt, 1, i);
+   nr_pages += amd64_csrow_nr_pages(pvt, 1, i);
 
get_cs_base_and_mask(pvt, i, 0, base, mask);
/* 8 bytes of resolution */
@@ -2204,7 +2205,7 @@ static int init_csrows(struct mem_ctl_info *mci)
mtype = amd64_determine_memory_type(pvt, i);
 
debugf1(  for MC node %d csrow %d:\n, pvt-mc_node_id, i);
-   debugf1(nr_pages: %u\n, csrow-nr_pages);
+   debugf1(nr_pages: %u\n, nr_pages * pvt-channel_count);
 
/*
 * determine whether CHIPKILL or JUST ECC or NO ECC is operating
@@ -2218,6 +2219,7 @@ static int init_csrows(struct mem_ctl_info *mci)
for (j = 0; j  pvt-channel_count; j++) {
csrow-channels[j].dimm-mtype = mtype;
csrow-channels[j].dimm-edac_mode = edac_mode;
+   csrow-channels[j].dimm-nr_pages = nr_pages;
}
}
 
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 

[PATCH EDAC v26 40/66] edac: Rename the parent dev to pdev

2012-05-18 Thread Mauro Carvalho Chehab
As EDAC doesn't use struct device itself, it created a parent dev
pointer called as pdev.  Now that we'll be converting it to use
struct device, instead of struct devsys, this needs to be fixed.

No functional changes.

Reviewed-by: Aristeu Rozanski aroza...@redhat.com
Acked-by: Chris Metcalf cmetc...@tilera.com
Cc: Doug Thompson nor...@yahoo.com
Cc: Borislav Petkov borislav.pet...@amd.com
Cc: Mark Gross mark.gr...@intel.com
Cc: Jason Uhlenkott juhle...@akamai.com
Cc: Tim Small t...@buttersideup.com
Cc: Ranganathan Desikan r...@jetztechnologies.com
Cc: Arvind R. arvin...@gmail.com
Cc: Olof Johansson o...@lixom.net
Cc: Egor Martovetsky e...@pasemi.com
Cc: Michal Marek mma...@suse.cz
Cc: Jiri Kosina jkos...@suse.cz
Cc: Joe Perches j...@perches.com
Cc: Dmitry Eremin-Solenikov dbarysh...@gmail.com
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Hitoshi Mitake h.mit...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Niklas Söderlund niklas.soderl...@ericsson.com
Cc: Shaohui Xie shaohui@freescale.com
Cc: Josh Boyer jwbo...@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
 drivers/edac/amd64_edac.c  |2 +-
 drivers/edac/amd76x_edac.c |4 ++--
 drivers/edac/cell_edac.c   |   12 ++--
 drivers/edac/cpc925_edac.c |2 +-
 drivers/edac/e752x_edac.c  |2 +-
 drivers/edac/e7xxx_edac.c  |2 +-
 drivers/edac/edac_mc.c |8 
 drivers/edac/edac_mc_sysfs.c   |2 +-
 drivers/edac/i3000_edac.c  |4 ++--
 drivers/edac/i3200_edac.c  |6 +++---
 drivers/edac/i5000_edac.c  |2 +-
 drivers/edac/i5100_edac.c  |2 +-
 drivers/edac/i5400_edac.c  |2 +-
 drivers/edac/i7300_edac.c  |2 +-
 drivers/edac/i7core_edac.c |4 ++--
 drivers/edac/i82443bxgx_edac.c |4 ++--
 drivers/edac/i82860_edac.c |4 ++--
 drivers/edac/i82875p_edac.c|4 ++--
 drivers/edac/i82975x_edac.c|4 ++--
 drivers/edac/mpc85xx_edac.c|4 ++--
 drivers/edac/mv64x60_edac.c|2 +-
 drivers/edac/pasemi_edac.c |6 +++---
 drivers/edac/ppc4xx_edac.c |8 
 drivers/edac/r82600_edac.c |4 ++--
 drivers/edac/sb_edac.c |4 ++--
 drivers/edac/tile_edac.c   |4 ++--
 drivers/edac/x38_edac.c|6 +++---
 include/linux/edac.h   |2 +-
 28 files changed, 56 insertions(+), 56 deletions(-)

diff --git a/drivers/edac/amd64_edac.c b/drivers/edac/amd64_edac.c
index 7be9b72..821bc2c 100644
--- a/drivers/edac/amd64_edac.c
+++ b/drivers/edac/amd64_edac.c
@@ -2601,7 +2601,7 @@ static int amd64_init_one_instance(struct pci_dev *F2)
goto err_siblings;
 
mci-pvt_info = pvt;
-   mci-dev = pvt-F2-dev;
+   mci-pdev = pvt-F2-dev;
 
setup_mci_misc_attrs(mci, fam_type);
 
diff --git a/drivers/edac/amd76x_edac.c b/drivers/edac/amd76x_edac.c
index 9388f3a..65e639c 100644
--- a/drivers/edac/amd76x_edac.c
+++ b/drivers/edac/amd76x_edac.c
@@ -105,7 +105,7 @@ static void amd76x_get_error_info(struct mem_ctl_info *mci,
 {
struct pci_dev *pdev;
 
-   pdev = to_pci_dev(mci-dev);
+   pdev = to_pci_dev(mci-pdev);
pci_read_config_dword(pdev, AMD76X_ECC_MODE_STATUS,
info-ecc_mode_status);
 
@@ -257,7 +257,7 @@ static int amd76x_probe1(struct pci_dev *pdev, int dev_idx)
return -ENOMEM;
 
debugf0(%s(): mci = %p\n, __func__, mci);
-   mci-dev = pdev-dev;
+   mci-pdev = pdev-dev;
mci-mtype_cap = MEM_FLAG_RDDR;
mci-edac_ctl_cap = EDAC_FLAG_NONE | EDAC_FLAG_EC | EDAC_FLAG_SECDED;
mci-edac_cap = ems_mode ?
diff --git a/drivers/edac/cell_edac.c b/drivers/edac/cell_edac.c
index 69ee6aa..2e5b953 100644
--- a/drivers/edac/cell_edac.c
+++ b/drivers/edac/cell_edac.c
@@ -36,7 +36,7 @@ static void cell_edac_count_ce(struct mem_ctl_info *mci, int 
chan, u64 ar)
struct csrow_info   *csrow = mci-csrows[0];
unsigned long   address, pfn, offset, syndrome;
 
-   dev_dbg(mci-dev, ECC CE err on node %d, channel %d, ar = 0x%016llx\n,
+   dev_dbg(mci-pdev, ECC CE err on node %d, channel %d, ar = 
0x%016llx\n,
priv-node, chan, ar);
 
/* Address decoding is likely a bit bogus, to dbl check */
@@ -59,7 +59,7 @@ static void cell_edac_count_ue(struct mem_ctl_info *mci, int 
chan, u64 ar)
struct csrow_info   *csrow = mci-csrows[0];
unsigned long   address, pfn, offset;
 
-   dev_dbg(mci-dev, ECC UE err on node %d, channel %d, ar = 0x%016llx\n,
+   dev_dbg(mci-pdev, ECC UE err on node %d, channel %d, ar = 
0x%016llx\n,
priv-node, chan, ar);
 
/* Address decoding is likely a bit bogus, to dbl check */
@@ -83,7 +83,7 @@ static void cell_edac_check(struct mem_ctl_info *mci)
fir = in_be64(priv-regs-mic_fir);
 #ifdef DEBUG
if (fir != priv-prev_fir) {
-  

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

2012-05-18 Thread Tabi Timur-B04825
On Wed, May 2, 2012 at 8:16 PM, David Daney ddaney.c...@gmail.com wrote:
 From: David Daney david.da...@cavium.com

 This code has been working well for about six months on a couple of
 different configurations (boards), so I thought it would be a good
 time to send it out again, and I hope get it on the path towards
 merging.

David,

I'm trying to implement this feature on our boards, which don't use
GPIOs but rather a memory-mapped FPGA.  I control the mux by setting
some bits in one of the FPGA registers.

Do you have a real device tree I can use as an example?

I'm not sure what the parent MDIO bus node is supposed to represent.
 Is that that device that actually controls the muxing hardware, which
in our case would be the FPGA?

-- 
Timur Tabi
Linux kernel developer at Freescale
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev


Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

2012-05-18 Thread David Daney

On 05/18/2012 02:42 PM, Tabi Timur-B04825 wrote:

On Wed, May 2, 2012 at 8:16 PM, David Daneyddaney.c...@gmail.com  wrote:

From: David Daneydavid.da...@cavium.com

This code has been working well for about six months on a couple of
different configurations (boards), so I thought it would be a good
time to send it out again, and I hope get it on the path towards
merging.


David,

I'm trying to implement this feature on our boards, which don't use
GPIOs but rather a memory-mapped FPGA.  I control the mux by setting
some bits in one of the FPGA registers.


You can either:

1) write a standard GPIO driver for the thing that controls the mux, and 
then use mdio-mux-gpio.c, or...


2) Write a new driver modeled on mdio-mux-gpio.c for your switch control.



Do you have a real device tree I can use as an example?



Attached.


I'm not sure what the parent MDIO bus node is supposed to represent.
  Is that that device that actually controls the muxing hardware


No.  It is the device that implements the master 802.3 clause {22,45} 
MDIO Station Management (STA) protocol.



, which in our case would be the FPGA?


I have no idea what your FPGA implements, so it is hard to say.

A sane person would implement a separate MDIO STA controller for each 
bus, in which case you wouldn't use the multiplexer driver.


Only people dealing with insane hardware need the multiplexer.  The 
patch in net-next has a nice ASCII art picture of such an insane design.


David Daney


ebb6600.dts
Description: audio/vnd.dts
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

2012-05-18 Thread Timur Tabi
David Daney wrote:
  I'm not sure what the parent MDIO bus node is supposed to represent.
Is that that device that actually controls the muxing hardware

 No.  It is the device that implements the master 802.3 clause {22,45} 
 MDIO Station Management (STA) protocol.

Ah, I think I get it.  It is *the* MDIO node that would normally exist if
muxing we're necessary on the board.  From the looks of it, that node
would look exactly the same if you didn't need muxing?

-- 
Timur Tabi
Linux kernel developer at Freescale

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


Re: [PATCH v6 0/3] netdev/of/phy: MDIO bus multiplexer support.

2012-05-18 Thread David Daney

On 05/18/2012 03:09 PM, Timur Tabi wrote:

David Daney wrote:

I'm not sure what the parent MDIO bus node is supposed to represent.
   Is that that device that actually controls the muxing hardware



No.  It is the device that implements the master 802.3 clause {22,45}
MDIO Station Management (STA) protocol.


Ah, I think I get it.  It is *the* MDIO node that would normally exist if
muxing we're necessary on the board.  From the looks of it, that node
would look exactly the same if you didn't need muxing?



Yes.  You may note in the DTS file I attached in the parent (sorry for 
the fubar mime types), that there are two, almost identical, MDIO 
masters.  smi0 has two directly attached PHYs.  smi1 goes to the mux, 
and each child of the mux has four attached PHYs.


This is a fairly complex configuration as the GPIOs controlling the MDIO 
mux are on I2C GPIO expanders which are themselves behind an I2C mux...


The nice thing about this is that the Linux I2C and MDIO infrastructure 
is all configured dynamically from the device tree and everything works 
well together with no locking issues.  The addition of the deferred 
driver probe mechanism was the last part of the puzzle (I think... 
actually I don't know if all my I2C things are merged yet...).


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