1. 06 12月, 2013 1 次提交
  2. 08 6月, 2013 1 次提交
  3. 04 1月, 2013 1 次提交
    • G
      Drivers: edac: remove __dev* attributes. · 9b3c6e85
      Greg Kroah-Hartman 提交于
      CONFIG_HOTPLUG is going away as an option.  As a result, the __dev*
      markings need to be removed.
      
      This change removes the use of __devinit, __devexit_p, and __devexit
      from these drivers.
      
      Based on patches originally written by Bill Pemberton, but redone by me
      in order to handle some of the coding style issues better, by hand.
      
      Cc: Bill Pemberton <wfp5p@virginia.edu>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: David Daney <david.daney@cavium.com>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b3c6e85
  4. 21 12月, 2012 1 次提交
  5. 28 11月, 2012 1 次提交
  6. 12 6月, 2012 7 次提交
  7. 11 6月, 2012 2 次提交
    • M
      edac: Rename the parent dev to pdev · fd687502
      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: NAristeu Rozanski <arozansk@redhat.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      fd687502
    • C
      edac: avoid mce decoding crash after edac driver unloaded · e35fca47
      Chen Gong 提交于
      Some edac drivers register themselves as mce decoders via
      notifier_chain. But in current notifier_chain implementation logic,
      it doesn't accept same notifier registered twice. If so, it will be
      wrong when adding/removing the element from the list. For example,
      on one SandyBridge platform, remove module sb_edac and then trigger
      one error, it will hit oops because it has no mce decoder registered
      but related notifier_chain still points to an invalid callback
      function. Here is an example:
      
      Call Trace:
       [<ffffffff8150ef6a>] atomic_notifier_call_chain+0x1a/0x20
       [<ffffffff8102b936>] mce_log+0x46/0x180
       [<ffffffff8102eaea>] apei_mce_report_mem_error+0x4a/0x60
       [<ffffffff812e19d2>] ghes_do_proc+0x192/0x210
       [<ffffffff812e2066>] ghes_proc+0x46/0x70
       [<ffffffff812e20d8>] ghes_notify_sci+0x48/0x80
       [<ffffffff8150ef05>] notifier_call_chain+0x55/0x80
       [<ffffffff81076f1a>] __blocking_notifier_call_chain+0x5a/0x80
       [<ffffffff812aea11>] ? acpi_os_wait_events_complete+0x23/0x23
       [<ffffffff81076f56>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff812ddc4d>] acpi_hed_notify+0x19/0x1b
       [<ffffffff812b16bd>] acpi_device_notify+0x19/0x1b
       [<ffffffff812beb38>] acpi_ev_notify_dispatch+0x67/0x7f
       [<ffffffff812aea3a>] acpi_os_execute_deferred+0x29/0x36
       [<ffffffff81069dc2>] process_one_work+0x132/0x450
       [<ffffffff8106bbcb>] worker_thread+0x17b/0x3c0
       [<ffffffff8106ba50>] ? manage_workers+0x120/0x120
       [<ffffffff81070aee>] kthread+0x9e/0xb0
       [<ffffffff81514724>] kernel_thread_helper+0x4/0x10
       [<ffffffff81070a50>] ? kthread_freezable_should_stop+0x70/0x70
       [<ffffffff81514720>] ? gs_change+0x13/0x13
      Code: f3 49 89 d4 45 85 ed 4d 89 c6 48 8b 0f 74 48 48 85 c9 75 17 eb 41
      0f 1f 80 00 00 00 00 41 83 ed 01 4c 89 f9 74 22 4d 85 ff 74 1d <4c> 8b
      79 08 4c 89 e2 48 89 de 48 89 cf ff 11 4d 85 f6 74 04 41
      RIP  [<ffffffff8150eef6>] notifier_call_chain+0x46/0x80
       RSP <ffff88042868fb20>
      CR2: ffffffffa01af838
      ---[ end trace 0100930068e73e6f ]---
      BUG: unable to handle kernel paging request at fffffffffffffff8
      IP: [<ffffffff810705b0>] kthread_data+0x10/0x20
      PGD 1a0d067 PUD 1a0e067 PMD 0
      Oops: 0000 [#2] SMP
      
      Only i7core_edac and sb_edac have such issues because they have more
      than one memory controller which means they have to register mce
      decoder many times.
      
      Cc: <stable@vger.kernel.org> # 3.2 and upper
      Signed-off-by: NChen Gong <gong.chen@linux.intel.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e35fca47
  8. 29 5月, 2012 8 次提交
    • M
      i7core: fix ranks information at the per-channel struct · 0bf09e82
      Mauro Carvalho Chehab 提交于
      There is a flag at the per-channel struct that indicates if there are
      any 4R dimm on it. The way the presence of this flag were reported
      is not ok, as it might give the false idea that the channel were filled
      with 2R memories:
      
      [  580.588701] EDAC DEBUG: get_dimm_config: Ch1 phy rd1, wr1 (0x063f7431): 2 ranks, UDIMMs
      [  580.588704] EDAC DEBUG: get_dimm_config: 	dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
      
      (in this case, just one 1R memory is filled on channel 1)
      
      So, use a better way to represent the per-channel ranks information.
      After the patch, it will show:
      
      [ 2002.233978] EDAC DEBUG: get_dimm_config: Ch0 phy rd0, wr0 (0x063f7431): UDIMMs
      [ 2002.233982] EDAC DEBUG: get_dimm_config: 	dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
      [ 2002.233988] EDAC DEBUG: get_dimm_config: 	dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
      
      (in this case, there isn't any 4R memories)
      Reported-by: NBorislav Petkov <borislav.petkov@amd.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0bf09e82
    • M
      edac: Cleanup the logs for i7core and sb edac drivers · e17a2f42
      Mauro Carvalho Chehab 提交于
      Remove some information that it is duplicated at the MCE log,
      and don't have much usage for the error. Those data will be
      added again, when creating a trace function that outputs both
      memory errors and MCE fields.
      
      Cc: Aristeu Rozanski <arozansk@redhat.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      e17a2f42
    • M
      edac: Remove the legacy EDAC ABI · ca0907b9
      Mauro Carvalho Chehab 提交于
      Now that all drivers got converted to use the new ABI, we can
      drop the old one.
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ca0907b9
    • M
      i7core_edac: convert driver to use the new edac ABI · 0975c16f
      Mauro Carvalho Chehab 提交于
      The legacy edac ABI is going to be removed. Port the driver to use
      and benefit from the new API functionality.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      0975c16f
    • M
      edac: move nr_pages to dimm struct · a895bf8b
      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: NAristeu Rozanski <arozansk@redhat.com>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a895bf8b
    • M
      edac: Don't initialize csrow's first_page & friends when not needed · 5e2af0c0
      Mauro Carvalho Chehab 提交于
      Almost all edac	drivers	initialize csrow_info->first_page,
      csrow_info->last_page and csrow_info->page_mask. Those vars are
      used inside the EDAC core, in order to calculate the csrow affected
      by an error, by using the routine edac_mc_find_csrow_by_page().
      
      However, very few drivers actually use it:
              e752x_edac.c
              e7xxx_edac.c
              i3000_edac.c
              i82443bxgx_edac.c
              i82860_edac.c
              i82875p_edac.c
              i82975x_edac.c
              r82600_edac.c
      
      There also a few other drivers that have their own calculus
      formula internally using those vars.
      
      All the others are just wasting time by initializing those
      data.
      
      While initializing data without using them won't cause any troubles, as
      those information is stored at the wrong place (at csrows structure), it
      is better to remove what is unused, in order to simplify the next patch.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Acked-by: NBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      5e2af0c0
    • M
      edac: move dimm properties to struct dimm_info · 084a4fcc
      Mauro Carvalho Chehab 提交于
      On systems based on chip select rows, all channels need to use memories
      with the same properties, otherwise the memories on channels A and B
      won't be recognized.
      
      However, such assumption is not true for all types of memory
      controllers.
      
      Controllers for FB-DIMM's don't have such requirements.
      
      Also, modern Intel controllers seem to be capable of handling such
      differences.
      
      So, we need to get rid of storing the DIMM information into a per-csrow
      data, storing it, instead at the right place.
      
      The first step is to move grain, mtype, dtype and edac_mode to the
      per-dimm struct.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: NBorislav Petkov <borislav.petkov@amd.com>
      Acked-by: NChris Metcalf <cmetcalf@tilera.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Borislav Petkov <borislav.petkov@amd.com>
      Cc: Mark Gross <mark.gross@intel.com>
      Cc: Jason Uhlenkott <juhlenko@akamai.com>
      Cc: Tim Small <tim@buttersideup.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Egor Martovetsky <egor@pasemi.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Joe Perches <joe@perches.com>
      Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Hitoshi Mitake <h.mitake@gmail.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: James Bottomley <James.Bottomley@parallels.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Cc: Josh Boyer <jwboyer@gmail.com>
      Cc: Mike Williams <mike@mikebwilliams.com>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      084a4fcc
    • M
      edac: Create a dimm struct and move the labels into it · a7d7d2e1
      Mauro Carvalho Chehab 提交于
      The way a DIMM is currently represented implies that they're
      linked into a per-csrow struct. However, some drivers don't see
      csrows, as they're ridden behind some chip like the AMB's
      on FBDIMM's, for example.
      
      This forced drivers to fake^Wvirtualize a csrow struct, and to create
      a mess under csrow/channel original's concept.
      
      Move the DIMM labels into a per-DIMM struct, and add there
      the real location of the socket, in terms of csrow/channel.
      Latter patches will modify the location to properly represent the
      memory architecture.
      
      All other drivers will use a per-csrow type of location.
      Some of those drivers will require a latter conversion, as
      they also fake the csrows internally.
      
      TODO: While this patch doesn't change the existing behavior, on
      csrows-based memory controllers, a csrow/channel pair points to a memory
      rank. There's a known bug at the EDAC core that allows having different
      labels for the same DIMM, if it has more than one rank. A latter patch
      is need to merge the several ranks for a DIMM into the same dimm_info
      struct, in order to avoid having different labels for the same DIMM.
      
      The edac_mc_alloc() will now contain a per-dimm initialization loop that
      will be changed by latter patches in order to match other types of
      memory architectures.
      Reviewed-by: NAristeu Rozanski <arozansk@redhat.com>
      Reviewed-by: NBorislav Petkov <borislav.petkov@amd.com>
      Cc: Doug Thompson <norsk5@yahoo.com>
      Cc: Ranganathan Desikan <ravi@jetztechnologies.com>
      Cc: "Arvind R." <arvino55@gmail.com>
      Cc: "Niklas Söderlund" <niklas.soderlund@ericsson.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      a7d7d2e1
  9. 30 4月, 2012 1 次提交
  10. 19 3月, 2012 1 次提交
  11. 14 12月, 2011 1 次提交
  12. 01 11月, 2011 11 次提交
  13. 19 8月, 2011 1 次提交
  14. 19 4月, 2011 1 次提交
  15. 31 3月, 2011 1 次提交
  16. 28 12月, 2010 1 次提交