1. 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
  2. 14 12月, 2012 1 次提交
  3. 12 12月, 2012 1 次提交
    • R
      MIPS: Cavium: Add EDAC support. · f65aad41
      Ralf Baechle 提交于
      Drivers for EDAC on Cavium.  Supported subsystems are:
      
       o CPU primary caches.  These are parity protected only, so only error
         reporting.
       o Second level cache - ECC protected, provides SECDED.
       o Memory: ECC / SECDEC if used with suitable DRAM modules.  The driver will
         will only initialize if ECC is enabled on a system so is safe to run on
         non-ECC memory.
       o PCI: Parity error reporting
      
      Since it is very hard to test this sort of code the implementation is very
      conservative and uses polling where possible for now.
      Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      Reviewed-by: NBorislav Petkov <borislav.petkov@amd.com>
      f65aad41
  4. 04 12月, 2012 1 次提交
  5. 28 11月, 2012 24 次提交
  6. 30 10月, 2012 1 次提交
  7. 25 10月, 2012 3 次提交
    • J
      i7300_edac: Fix error flag testing · 7e06b7a3
      Jean Delvare 提交于
      * Right-shift the values in GET_FBD_FAT_IDX and GET_FBD_NF_IDX, so
        that the callers get the result they expect.
      * Fix definition of FERR_FAT_FBD_ERR_MASK.
      * Call GET_FBD_NF_IDX, not GET_FBD_FAT_IDX, when operating on
        register FERR_NF_FBD. We were lucky they have the same definition.
      
      This fixes kernel bug #44131:
      https://bugzilla.kernel.org/show_bug.cgi?id=44131Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      7e06b7a3
    • M
      edac: Fix the dimm filling for csrows-based layouts · 24bef66e
      Mauro Carvalho Chehab 提交于
      The driver is currently filling data in a wrong way, on drivers
      for csrows-based memory controller, when the first layer is a
      csrow.
      
      This is not easily to notice, as, in general, memories are
      filed in dual, interleaved, symetric mode, as very few memory
      controllers support asymetric modes.
      
      While digging into a bug for i82795_edac driver, the asymetric
      mode there is now working, allowing us to fill the machine with
      4x1GB ranks at channel 0, and 2x512GB at channel 1:
      
      Channel 0 ranks:
      EDAC DEBUG: i82975x_init_csrows: DIMM A0: from page 0x00000000 to 0x0003ffff (size: 0x00040000 pages)
      EDAC DEBUG: i82975x_init_csrows: DIMM A1: from page 0x00040000 to 0x0007ffff (size: 0x00040000 pages)
      EDAC DEBUG: i82975x_init_csrows: DIMM A2: from page 0x00080000 to 0x000bffff (size: 0x00040000 pages)
      EDAC DEBUG: i82975x_init_csrows: DIMM A3: from page 0x000c0000 to 0x000fffff (size: 0x00040000 pages)
      
      Channel 1 ranks:
      EDAC DEBUG: i82975x_init_csrows: DIMM B0: from page 0x00100000 to 0x0011ffff (size: 0x00020000 pages)
      EDAC DEBUG: i82975x_init_csrows: DIMM B1: from page 0x00120000 to 0x0013ffff (size: 0x00020000 pages)
      
      Instead of properly showing the memories as such, before this patch, it
      shows the memory layout as:
      
                +-----------------------------------+
                |                mc0                |
                |  csrow0   |  csrow1   |  csrow2   |
      ----------+-----------------------------------+
      channel1: |  1024 MB  |  1024 MB  |   512 MB  |
      channel0: |  1024 MB  |  1024 MB  |   512 MB  |
      ----------+-----------------------------------+
      
      as if both channels were symetric, grouping the DIMMs on a wrong
      layout.
      
      After this patch, the memory is correctly represented.
      So, for csrows at layers[0], it shows:
      
                +-----------------------------------------------+
                |                      mc0                      |
                |  csrow0   |  csrow1   |  csrow2   |  csrow3   |
      ----------+-----------------------------------------------+
      channel1: |   512 MB  |   512 MB  |     0 MB  |     0 MB  |
      channel0: |  1024 MB  |  1024 MB  |  1024 MB  |  1024 MB  |
      ----------+-----------------------------------------------+
      
      For csrows at layers[1], it shows:
      
              +-----------------------+
              |          mc0          |
              | channel0  | channel1  |
      --------+-----------------------+
      csrow3: |  1024 MB  |     0 MB  |
      csrow2: |  1024 MB  |     0 MB  |
      --------+-----------------------+
      csrow1: |  1024 MB  |   512 MB  |
      csrow0: |  1024 MB  |   512 MB  |
      --------+-----------------------+
      
      So, no matter of what comes first, the information between
      channel and csrow will be properly represented.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      24bef66e
    • M
      i82975x_edac: Fix dimm label initialization · 47969684
      Mauro Carvalho Chehab 提交于
      The driver has only 4 hardcoded labels, but allows much more memory.
      Fix it by removing the hardcoded logic, using snprintf() instead.
      
      [   19.833972] general protection fault: 0000 [#1] SMP
      [   19.837733] Modules linked in: i82975x_edac(+) edac_core firewire_ohci firewire_core crc_itu_t nouveau mxm_wmi wmi video i2c_algo_bit drm_kms_helper ttm drm i2c_core
      [   19.837733] CPU 0
      [   19.837733] Pid: 390, comm: udevd Not tainted 3.6.1-1.fc17.x86_64.debug #1 Dell Inc.                 Precision WorkStation 390    /0MY510
      [   19.837733] RIP: 0010:[<ffffffff813463a8>]  [<ffffffff813463a8>] strncpy+0x18/0x30
      [   19.837733] RSP: 0018:ffff880078535b68  EFLAGS: 00010202
      [   19.837733] RAX: ffff880069fa9708 RBX: ffff880078588000 RCX: ffff880069fa9708
      [   19.837733] RDX: 000000000000001f RSI: 5f706f5f63616465 RDI: ffff880069fa9708
      [   19.837733] RBP: ffff880078535b68 R08: ffff880069fa9727 R09: 000000000000fffe
      [   19.837733] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000003
      [   19.837733] R13: 0000000000000000 R14: ffff880069fa9290 R15: ffff880079624a80
      [   19.837733] FS:  00007f3de01ee840(0000) GS:ffff88007c400000(0000) knlGS:0000000000000000
      [   19.837733] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   19.837733] CR2: 00007f3de00b9000 CR3: 0000000078dbc000 CR4: 00000000000007f0
      [   19.837733] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [   19.837733] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [   19.837733] Process udevd (pid: 390, threadinfo ffff880078534000, task ffff880079642450)
      [   19.837733] Stack:
      [   19.837733]  ffff880078535c18 ffffffffa017c6b8 00040000816d627f ffff880079624a88
      [   19.837733]  ffffc90004cd6000 ffff880079624520 ffff88007ac21148 0000000000000000
      [   19.837733]  0000000000000000 0004000000000000 feda000078535bc8 ffffffff810d696d
      [   19.837733] Call Trace:
      [   19.837733]  [<ffffffffa017c6b8>] i82975x_init_one+0x2e6/0x3e6 [i82975x_edac]
      ...
      
      Fix bug reported at:
      	https://bugzilla.redhat.com/show_bug.cgi?id=848149
      And, very likely:
      	https://bbs.archlinux.org/viewtopic.php?id=148033
      	https://bugzilla.kernel.org/show_bug.cgi?id=47171
      
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      47969684
  8. 24 10月, 2012 1 次提交
  9. 25 9月, 2012 3 次提交
    • M
      sb_edac: Avoid overflow errors at memory size calculation · deb09dda
      Mauro Carvalho Chehab 提交于
      Sandy bridge EDAC is calculating the memory size with overflow.
      Basically, the size field and the integer calculation is using 32 bits.
      More bits are needed, when the DIMM memories have high density.
      
      The net result is that memories are improperly reported there, when
      high-density DIMMs are used:
      
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 0, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 591: mc#0: channel 1, dimm 0, -16384 Mb (-4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      
      As the number of pages value is handled at the EDAC core as unsigned
      ints, the driver shows the 16 GB memories at sysfs interface as 16760832
      MB! The fix is simple: calculate the number of pages as unsigned 64-bits
      integer.
      
      After the patch, the memory size (16 GB) is properly detected:
      
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 0, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      EDAC DEBUG: in drivers/edac/sb_edac.c, line at 592: mc#0: channel 1, dimm 0, 16384 Mb (4194304 pages) bank: 8, rank: 2, row: 0x10000, col: 0x800
      
      Cc: stable@kernel.org
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      deb09dda
    • M
      i5000: Fix the memory size calculation with 2R memories · b70f8333
      Mauro Carvalho Chehab 提交于
      When 2R memories are found, the memory size should be multiplied
      by two, otherwise, it will report half of the memory size:
      
             +-----------------------------------------------+
             |                      mc0                      |
             |        branch0        |        branch1        |
             | channel0  | channel1  | channel0  | channel1  |
      -------+-----------------------------------------------+
      slot3: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      slot2: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      -------+-----------------------------------------------+
      slot1: |     0 MB  |     0 MB  |     0 MB  |     0 MB  |
      slot0: |  1024 MB  |  1024 MB  |  1024 MB  |  1024 MB  |
      -------+-----------------------------------------------+
      
      (the above machine have 4 x 2GB 2R memories)
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      b70f8333
    • M
      i3200_edac: Fix memory rank size · 582a8996
      Mauro Carvalho Chehab 提交于
      commit a895bf8b incorrectly
      changed the logic that fills the memory bank size. Fix it.
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      582a8996
  10. 24 9月, 2012 2 次提交
    • S
      edac_mc: edac_mc_free() cannot assume mem_ctl_info is registered in sysfs. · faa2ad09
      Shaun Ruffell 提交于
      Fix potential NULL pointer dereference in edac_unregister_sysfs() on
      system boot introduced in 3.6-rc1.
      
      Since commit 7a623c03 ("edac: rewrite the sysfs code to use struct
      device") edac_mc_alloc() no longer initializes embedded kobjects in
      struct mem_ctl_info.  Therefore edac_mc_free() can no longer simply
      decrement a kobject reference count to free the allocated memory unless
      the memory controller driver module had also called edac_mc_add_mc().
      
      Now edac_mc_free() will check if the newly embedded struct device has
      been registered with sysfs before using either the standard device
      release functions or freeing the data structures itself with logic
      pulled out of the error path of edac_mc_alloc().
      
      The BUG this patch resolves for me:
      
        BUG: unable to handle kernel NULL pointer dereference at   (null)
        EIP is at __wake_up_common+0x1a/0x6a
        Process modprobe (pid: 933, ti=f3dc6000 task=f3db9520 task.ti=f3dc6000)
        Call Trace:
          complete_all+0x3f/0x50
          device_pm_remove+0x23/0xa2
          device_del+0x34/0x142
          edac_unregister_sysfs+0x3b/0x5c [edac_core]
          edac_mc_free+0x29/0x2f [edac_core]
          e7xxx_probe1+0x268/0x311 [e7xxx_edac]
          e7xxx_init_one+0x56/0x61 [e7xxx_edac]
          local_pci_probe+0x13/0x15
        ...
      
      Cc: Mauro Carvalho Chehab <mchehab@redhat.com>
      Cc: Shaohui Xie <Shaohui.Xie@freescale.com>
      Signed-off-by: NShaun Ruffell <sruffell@digium.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      faa2ad09
    • F
      edac_mc: fix messy kfree calls in the error path · ef6e7816
      Fengguang Wu 提交于
      coccinelle warns about:
      
      + drivers/edac/edac_mc.c:429:9-23: ERROR: reference preceded by free on line 429
      
         421         if (mci->csrows) {
       > 422                 for (chn = 0; chn < tot_channels; chn++) {
         423                         csr = mci->csrows[chn];
         424                         if (csr) {
       > 425                                 for (chn = 0; chn < tot_channels; chn++)
         426                                          kfree(csr->channels[chn]);
         427                                  kfree(csr);
         428                          }
       > 429                          kfree(mci->csrows[i]);
         430                  }
         431                  kfree(mci->csrows);
         432          }
      
      and that code block seem to mess things up in several ways (double free, memory
      leak, out-of-bound reads etc.):
      
      L422: The iterator "chn" and bound "tot_channels" are totally wrong. Should be
            "row" and "tot_csrows" respectively. Which means either memory leak, or
            out-of-bound reads (which if does not trigger an immediate page fault
            error, will further lead to kfree() on random addresses).
      
      L425: The inner loop is reusing the same iterator "chn" as the outer loop,
            which could lead to premature end of the outer loop, and hence memory leak.
      
      L429: The array index 'i' in mci->csrows[i] is a temporary value used in
            previous loops, and won't change at all in the current loop. Which
            means either out-of-bound read and possibly kfree(random number), or the
            same mci->csrows[i] get freed once and again, and possibly double free
            for the kfree(csr) in L427.
      
      L426/L427: a kfree(csr->channels) is needed in between to avoid leaking the memory.
      
      The buggy code was introduced by commit de3910eb ("edac: change the mem
      allocation scheme to make Documentation/kobject.txt happy") in the 3.6-rc1
      merge window. Fix it by freeing up resources in this order:
      
        free csrows[i]->channels[j]
        free csrows[i]->channels
        free csrows[i]
        free csrows
      
      CC: Mauro Carvalho Chehab <mchehab@redhat.com>
      CC: Shaun Ruffell <sruffell@digium.com>
      Signed-off-by: NFengguang Wu <fengguang.wu@intel.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      ef6e7816
  11. 13 9月, 2012 1 次提交
  12. 14 8月, 2012 1 次提交
    • T
      workqueue: use mod_delayed_work() instead of cancel + queue · 41f63c53
      Tejun Heo 提交于
      Convert delayed_work users doing cancel_delayed_work() followed by
      queue_delayed_work() to mod_delayed_work().
      
      Most conversions are straight-forward.  Ones worth mentioning are,
      
      * drivers/edac/edac_mc.c: edac_mc_workq_setup() converted to always
        use mod_delayed_work() and cancel loop in
        edac_mc_reset_delay_period() is dropped.
      
      * drivers/platform/x86/thinkpad_acpi.c: No need to remember whether
        watchdog is active or not.  @fan_watchdog_active and related code
        dropped.
      
      * drivers/power/charger-manager.c: Seemingly a lot of
        delayed_work_pending() abuse going on here.
        [delayed_]work_pending() are unsynchronized and racy when used like
        this.  I converted one instance in fullbatt_handler().  Please
        conver the rest so that it invokes workqueue APIs for the intended
        target state rather than trying to game work item pending state
        transitions.  e.g. if timer should be modified - call
        mod_delayed_work(), canceled - call cancel_delayed_work[_sync]().
      
      * drivers/thermal/thermal_sys.c: thermal_zone_device_set_polling()
        simplified.  Note that round_jiffies() calls in this function are
        meaningless.  round_jiffies() work on absolute jiffies not delta
        delay used by delayed_work.
      
      v2: Tomi pointed out that __cancel_delayed_work() users can't be
          safely converted to mod_delayed_work().  They could be calling it
          from irq context and if that happens while delayed_work_timer_fn()
          is running, it could deadlock.  __cancel_delayed_work() users are
          dropped.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NHenrique de Moraes Holschuh <hmh@hmh.eng.br>
      Acked-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Acked-by: NAnton Vorontsov <cbouatmailru@gmail.com>
      Acked-by: NDavid Howells <dhowells@redhat.com>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Roland Dreier <roland@kernel.org>
      Cc: "John W. Linville" <linville@tuxdriver.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Len Brown <len.brown@intel.com>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Johannes Berg <johannes@sipsolutions.net>
      41f63c53