1. 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
  2. 12 11月, 2015 33 次提交
  3. 11 11月, 2015 2 次提交
    • A
      MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() · a7f4df4e
      Alex Smith 提交于
      Add user-mode implementations of gettimeofday() and clock_gettime() to
      the VDSO. This is currently usable with 2 clocksources: the CP0 count
      register, which is accessible to user-mode via RDHWR on R2 and later
      cores, or the MIPS Global Interrupt Controller (GIC) timer, which
      provides a "user-mode visible" section containing a mirror of its
      counter registers. This section must be mapped into user memory, which
      is done below the VDSO data page.
      
      When a supported clocksource is not in use, the VDSO functions will
      return -ENOSYS, which causes libc to fall back on the standard syscall
      path.
      
      When support for neither of these clocksources is compiled into the
      kernel at all, the VDSO still provides clock_gettime(), as the coarse
      realtime/monotonic clocks can still be implemented. However,
      gettimeofday() is not provided in this case as nothing can be done
      without a suitable clocksource. This causes the symbol lookup to fail
      in libc and it will then always use the standard syscall path.
      
      This patch includes a workaround for a bug in QEMU which results in
      RDHWR on the CP0 count register always returning a constant (incorrect)
      value. A fix for this has been submitted, and the workaround can be
      removed after the fix has been in stable releases for a reasonable
      amount of time.
      
      A simple performance test which calls gettimeofday() 1000 times in a
      loop and calculates the average execution time gives the following
      results on a Malta + I6400 (running at 20MHz):
      
       - Syscall:    ~31000 ns
       - VDSO (GIC): ~15000 ns
       - VDSO (CP0): ~9500 ns
      
      [markos.chandras@imgtec.com:
      - Minor code re-arrangements in order for mappings to be made
      in the order they appear to the process' address space.
      - Move do_{monotonic, realtime} outside of the MIPS_CLOCK_VSYSCALL ifdef
      - Use gic_get_usm_range so we can do the GIC mapping in the
      arch/mips/kernel/vdso instead of the GIC irqchip driver]
      Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/11338/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      a7f4df4e
    • A
      irqchip: irq-mips-gic: Provide function to map GIC user section · c0a9f72c
      Alex Smith 提交于
      The GIC provides a "user-mode visible" section containing a mirror of
      the counter registers which can be mapped into user memory. This will
      be used by the VDSO time function implementations, so provide a
      function to map it in.
      
      When the GIC is not enabled in Kconfig a dummy inline version of this
      function is provided, along with "#define gic_present 0", so that we
      don't have to litter the VDSO code with ifdefs.
      
      [markos.chandras@imgtec.com:
        - Move mapping code to arch/mips/kernel/vdso.c and use a resource
          type to get the GIC usermode information
        - Avoid renaming function arguments and use __gic_base_addr to hold
          the base GIC address prior to ioremap.]
      [ralf@linux-mips.org: Fix up gic_get_usm_range() to compile and make inline
      again.]
      Signed-off-by: NAlex Smith <alex.smith@imgtec.com>
      Signed-off-by: NMarkos Chandras <markos.chandras@imgtec.com>
      Reviewed-by: NMarc Zyngier <marc.zyngier@arm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alex Smith <alex.smith@imgtec.com>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: http://patchwork.linux-mips.org/patch/11281/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      c0a9f72c