1. 11 12月, 2015 7 次提交
    • B
      EDAC: Make edac_device workqueue setup/teardown functions static · e136fa01
      Borislav Petkov 提交于
      They're not used anywhere else.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      e136fa01
    • B
      EDAC: Remove edac_get_sysfs_subsys() error handling · d4538000
      Borislav Petkov 提交于
      It cannot fail now. We either load EDAC core after having successfully
      initialized edac_subsys or we don't.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      d4538000
    • B
      EDAC: Unexport and make edac_subsys static · a97d2627
      Borislav Petkov 提交于
      ... and use the accessor instead.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      a97d2627
    • B
      EDAC: Rip out the edac_subsys reference counting · 733476cf
      Borislav Petkov 提交于
      This was really dumb - reference counting for the main EDAC sysfs
      object. While we could've simply registered it as the first thing in the
      module init path and then hand it around to what needs it.
      
      Do that and rip out all the code around it, thus simplifying the whole
      handling significantly.
      
      Move the edac_subsys node back to edac_module.c.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      733476cf
    • B
      EDAC: Robustify workqueues destruction · fcd5c4dd
      Borislav Petkov 提交于
      EDAC workqueue destruction is really fragile. We cancel delayed work
      but if it is still running and requeues itself, we still go ahead and
      destroy the workqueue and the queued work explodes when workqueue core
      attempts to run it.
      
      Make the destruction more robust by switching op_state to offline so
      that requeuing stops. Cancel any pending work *synchronously* too.
      
        EDAC i7core: Driver loaded.
        general protection fault: 0000 [#1] SMP
        CPU 12
        Modules linked in:
        Supported: Yes
        Pid: 0, comm: kworker/0:1 Tainted: G          IE   3.0.101-0-default #1 HP ProLiant DL380 G7
        RIP: 0010:[<ffffffff8107dcd7>]  [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
        < ... regs ...>
        Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
        Stack:
         ...
        Call Trace:
         call_timer_fn
         run_timer_softirq
         __do_softirq
         call_softirq
         do_softirq
         irq_exit
         smp_apic_timer_interrupt
         apic_timer_interrupt
         intel_idle
         cpuidle_idle_call
         cpu_idle
        Code: ...
        RIP  __queue_work
         RSP <...>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: <stable@vger.kernel.org>
      fcd5c4dd
    • B
      EDAC, mc_sysfs: Fix freeing bus' name · 12e26969
      Borislav Petkov 提交于
      I get the splat below when modprobing/rmmoding EDAC drivers. It happens
      because bus->name is invalid after bus_unregister() has run. The Code: section
      below corresponds to:
      
        .loc 1 1108 0
        movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
        .loc 1 1109 0
        popq    %rbx    #
      
        .loc 1 1108 0
        movq    (%rax), %rdi    # _7->name,
        jmp     kfree   #
      
      and %rax has some funky stuff 2030203020312030 which looks a lot like
      something walked over it.
      
      Fix that by saving the name ptr before doing stuff to string it points to.
      
        general protection fault: 0000 [#1] SMP
        Modules linked in: ...
        CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ #48
        Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
        task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
        RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
        RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
        RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
        RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
        RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
        R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
        R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
        FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
        Stack:
        Call Trace:
          i7core_unregister_mci.isra.9
          i7core_remove
          pci_device_remove
          __device_release_driver
          driver_detach
          bus_remove_driver
          pci_unregister_driver
          i7core_exit
          SyS_delete_module
          system_call_fastpath
          0x7fc9bf426536
        Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
        RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
         RSP <ffff88030da3fe28>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: <stable@vger.kernel.org> # v3.6..
      Fixes: 7a623c03 ("edac: rewrite the sysfs code to use struct device")
      12e26969
    • S
      EDAC, mpc85xx: Make mpc85xx-pci-edac a platform device · 666db563
      Scott Wood 提交于
      Originally the mpc85xx-pci-edac driver bound directly to the PCI
      controller node.
      
      Commit
      
        905e75c4 ("powerpc/fsl-pci: Unify pci/pcie initialization code")
      
      turned the PCI controller code into a platform device. Since we can't
      have two drivers binding to the same device, the EDAC code was changed
      to be called into as a library-style submodule. However, this doesn't
      work if the EDAC driver is built as a module.
      
      Commit
      
        8d8fcba6d1ea ("EDAC: Rip out the edac_subsys reference counting")
      
      exposed another problem with this approach -- mpc85xx_pci_err_probe()
      was being called in the same early boot phase that the PCI controller
      is initialized, rather than in the device_initcall phase that the EDAC
      layer expects. This caused a crash on boot.
      
      To fix this, the PCI controller code now creates a child platform device
      specifically for EDAC, which the mpc85xx-pci-edac driver binds to.
      Reported-by: NMichael Ellerman <mpe@ellerman.id.au>
      Reviewed-by: NJohannes Thumshirn <jthumshirn@suse.de>
      Signed-off-by: NScott Wood <scottwood@freescale.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Daniel Axtens <dja@axtens.net>
      Cc: Doug Thompson <dougthompson@xmission.com>
      Cc: Jia Hongtao <B38951@freescale.com>
      Cc: Jiri Kosina <jkosina@suse.com>
      Cc: Kim Phillips <kim.phillips@freescale.com>
      Cc: linux-edac <linux-edac@vger.kernel.org>
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: Masanari Iida <standby24x7@gmail.com>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Rob Herring <robh@kernel.org>
      Link: http://lkml.kernel.org/r/1449774432-18593-1-git-send-email-scottwood@freescale.comSigned-off-by: NBorislav Petkov <bp@suse.de>
      666db563
  2. 06 12月, 2015 3 次提交
  3. 03 12月, 2015 2 次提交
  4. 18 11月, 2015 1 次提交
  5. 13 11月, 2015 5 次提交
    • S
      mpt3sas: fix inline markers on non inline function declarations · 0a5149ba
      Stephen Rothwell 提交于
      After merging the scsi tree, today's linux-next build (powerpc
      allyesconfig) failed like this:
      
      In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
      drivers/scsi/mpt3sas/mpt3sas_scsih.c: In function '_scsih_io_done':
      drivers/scsi/mpt3sas/mpt3sas_base.h:1414:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_get': function body not available
       mpt3sas_scsi_direct_io_get(struct MPT3SAS_ADAPTER *ioc, u16 smid);
       ^
      drivers/scsi/mpt3sas/mpt3sas_scsih.c:4448:6: error: called from here
        if (mpt3sas_scsi_direct_io_get(ioc, smid) &&
            ^
      In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:59:0:
      drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
       mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
       ^
      drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
         mpt3sas_scsi_direct_io_set(ioc, smid, 0);
         ^
      In file included from drivers/scsi/mpt3sas/mpt3sas_scsih.c:5
      9:0:
      drivers/scsi/mpt3sas/mpt3sas_base.h:1416:1: error: inlining failed in call to always_inline 'mpt3sas_scsi_direct_io_set': function body not available
       mpt3sas_scsi_direct_io_set(struct MPT3SAS_ADAPTER *ioc, u16 smid, u8 direct_io);
       ^
      drivers/scsi/mpt3sas/mpt3sas_scsih.c:4454:3: error: called from here
         mpt3sas_scsi_direct_io_set(ioc, smid, 0);
         ^
      
      Presumably caused by commit
      
        c84b06a4 ("mpt3sas: Single driver module which supports both SAS 2.0 & SAS 3.0 HBAs")
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NJames Bottomley <JBottomley@Odin.com>
      0a5149ba
    • M
      Revert "drm/rockchip: Convert the probe function to the generic drm_of_component_probe()" · 5bad7d29
      Mark Yao 提交于
      This reverts commit 52f5eb60.
      
      Rockchip drm can't work with generic drm_of_component_probe now
      Signed-off-by: NMark Yao <mark.yao@rock-chips.com>
      Acked-by: NLiviu Dudau <Liviu.Dudau@arm.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      5bad7d29
    • V
      drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() wasn't called · 0c545ac4
      Ville Syrjälä 提交于
      Seems the crtc helpers call drm_calc_timestamping_constants()
      unconditionally even if the driver didn't initialize vblank support by
      calling drm_vblank_init(). That used to be OK since the constants were
      stored under drm_crtc.
      
      However I broke this with
      commit eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
      when I moved the constants to live inside the drm_vblank_crtc struct
      instead. If drm_vblank_init() isn't called, we don't allocate these
      structures, and so drm_calc_timestamping_constants() will oops.
      
      Fix it by adding a check into drm_calc_timestamping_constants() to see
      if vblank support was initialized at all. And to keep in line with other
      such checks, also toss in a check and warn for the case where vblank
      support was initialized, but the wrong number of crtcs was specified.
      
      Fixes the following sort of oops:
       BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
       IP: [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
       PGD 0
       Oops: 0002 [#1] SMP
       Modules linked in: sr_mod cdrom mgag200(+) i2c_algo_bit drm_kms_helper ahci syscopyarea sysfillrect sysimgblt libahci fb_sys_fops bnx2x ttm tg3(+) mdio drm ptp sd_mod libata i2c_core pps_core libcrc32c hpsa dm_mirror dm_region_hash dm_log dm_mod
       CPU: 0 PID: 418 Comm: kworker/0:2 Not tainted 4.3.0+ #1
       Hardware name: HP ProLiant DL380 Gen9, BIOS P89 06/09/2015
       Workqueue: events work_for_cpu_fn
       task: ffff88046ca95500 ti: ffff88007830c000 task.ti: ffff88007830c000
       RIP: 0010:[<ffffffffa014b266>]  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
       RSP: 0018:ffff88007830f4e8  EFLAGS: 00010246
       RAX: 0000000000fe4c00 RBX: ffff88006a849160 RCX: 0000000000000540
       RDX: 0000000000000000 RSI: 000000000000fde8 RDI: ffff88006a849000
       RBP: ffff88007830f518 R08: ffff88007830c000 R09: 00000001b87e3712
       R10: 00000000000050c4 R11: 0000000000000000 R12: 0000000000fe4c00
       R13: ffff88006a849000 R14: 0000000000000000 R15: 000000000000fde8
       FS:  0000000000000000(0000) GS:ffff88046f800000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 00000000000000b0 CR3: 00000000019d6000 CR4: 00000000001406f0
       Stack:
        ffff88007830f518 ffff88006a849000 ffff880c69b90340 ffff880c69b90000
        ffff880c69b90348 ffff880c69b90340 ffff88007830f748 ffffffffa042f7e7
        ffff88006a849090 0000000000000000 ffff88006a849160 0000000000000000
       Call Trace:
        [<ffffffffa042f7e7>] drm_crtc_helper_set_mode+0x3d7/0x4b0 [drm_kms_helper]
        [<ffffffffa04307d4>] drm_crtc_helper_set_config+0x8d4/0xb10 [drm_kms_helper]
        [<ffffffffa01548d4>] drm_mode_set_config_internal+0x64/0x100 [drm]
        [<ffffffffa043c342>] drm_fb_helper_pan_display+0xa2/0x280 [drm_kms_helper]
        [<ffffffff81392c7b>] fb_pan_display+0xbb/0x170
        [<ffffffff8138cf70>] bit_update_start+0x20/0x50
        [<ffffffff8138b81b>] fbcon_switch+0x39b/0x590
        [<ffffffff8140a3d0>] redraw_screen+0x1a0/0x240
        [<ffffffff8140b30e>] do_bind_con_driver+0x2ee/0x310
        [<ffffffff8140b651>] do_take_over_console+0x141/0x1b0
        [<ffffffff81387377>] do_fbcon_takeover+0x57/0xb0
        [<ffffffff8138c98b>] fbcon_event_notify+0x60b/0x750
        [<ffffffff810a5599>] notifier_call_chain+0x49/0x70
        [<ffffffff810a58dd>] __blocking_notifier_call_chain+0x4d/0x70
        [<ffffffff810a5916>] blocking_notifier_call_chain+0x16/0x20
        [<ffffffff8139282b>] fb_notifier_call_chain+0x1b/0x20
        [<ffffffff81394881>] register_framebuffer+0x1f1/0x330
        [<ffffffffa043d9aa>] drm_fb_helper_initial_config+0x27a/0x3d0 [drm_kms_helper]
        [<ffffffffa0469b4d>] mgag200_fbdev_init+0xdd/0xf0 [mgag200]
        [<ffffffffa0468586>] mgag200_modeset_init+0x176/0x1e0 [mgag200]
        [<ffffffffa0464659>] mgag200_driver_load+0x3f9/0x580 [mgag200]
        [<ffffffffa014e067>] drm_dev_register+0xa7/0xb0 [drm]
        [<ffffffffa015054f>] drm_get_pci_dev+0x8f/0x1e0 [drm]
        [<ffffffffa046937b>] mga_pci_probe+0x9b/0xc0 [mgag200]
        [<ffffffff813662d5>] local_pci_probe+0x45/0xa0
        [<ffffffff8109afe4>] work_for_cpu_fn+0x14/0x20
        [<ffffffff8109e13c>] process_one_work+0x14c/0x3c0
        [<ffffffff8109eaa4>] worker_thread+0x244/0x470
        [<ffffffff8168bfba>] ? __schedule+0x2aa/0x760
        [<ffffffff8109e860>] ? rescuer_thread+0x310/0x310
        [<ffffffff810a4438>] kthread+0xd8/0xf0
        [<ffffffff810a4360>] ? kthread_park+0x60/0x60
        [<ffffffff8169030f>] ret_from_fork+0x3f/0x70
        [<ffffffff810a4360>] ? kthread_park+0x60/0x60
       Code: f6 31 d2 41 89 c2 8b 83 b4 00 00 00 0f af c1 48 98 48 69 c0 40 42 0f 00 48 f7 f6 f6 43 74 10 41 89 c4 75 26 f6 05 9a 6f 03 00 01 <45> 89 96 b0 00 00 00 45 89 a6 ac 00 00 00 75 35 48 83 c4 08 5b
       RIP  [<ffffffffa014b266>] drm_calc_timestamping_constants+0x86/0x130 [drm]
        RSP <ffff88007830f4e8>
       CR2: 00000000000000b0
      
      Cc: Jeff Moyer <jmoyer@redhat.com>
      Reported-by: NJeff Moyer <jmoyer@redhat.com>
      References: http://lists.freedesktop.org/archives/dri-devel/2015-November/094217.html
      Fixes: eba1f35d ("drm: Move timestamping constants into drm_vblank_crtc")
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      0c545ac4
    • D
      libnvdimm, pmem: fix size trim in pmem_direct_access() · 589e75d1
      Dan Williams 提交于
      This masking prevents access to the end of the device via dax_do_io(),
      and is unnecessary as arch_add_memory() would have rejected an unaligned
      allocation.
      
      Cc: <stable@vger.kernel.org>
      Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      589e75d1
    • D
      libnvdimm, e820: fix numa node for e820-type-12 pmem ranges · f7256dc0
      Dan Williams 提交于
      Rather than punt on the numa node for these e820 ranges try to find a
      better answer with memory_add_physaddr_to_nid() when it is available.
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NBoaz Harrosh <boaz@plexistor.com>
      Tested-by: NBoaz Harrosh <boaz@plexistor.com>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      f7256dc0
  6. 12 11月, 2015 22 次提交