/* * CPPC (Collaborative Processor Performance Control) methods used * by CPUfreq drivers. * * (C) Copyright 2014, 2015 Linaro Ltd. * Author: Ashwin Chaugule * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License * as published by the Free Software Foundation; version 2 * of the License. */ #ifndef _CPPC_ACPI_H #define _CPPC_ACPI_H #include #include #include #include /* Only support CPPCv2 for now. */ #define CPPC_NUM_ENT 21 #define CPPC_REV 2 #define PCC_CMD_COMPLETE_MASK (1 << 0) #define PCC_ERROR_MASK (1 << 2) #define MAX_CPC_REG_ENT 19 /* CPPC specific PCC commands. */ #define CMD_READ 0 #define CMD_WRITE 1 /* Each register has the folowing format. */ struct cpc_reg { u8 descriptor; u16 length; u8 space_id; u8 bit_width; u8 bit_offset; u8 access_width; u64 __iomem address; } __packed; /* * Each entry in the CPC table is either * of type ACPI_TYPE_BUFFER or * ACPI_TYPE_INTEGER. */ struct cpc_register_resource { acpi_object_type type; u64 __iomem *sys_mem_vaddr; union { struct cpc_reg reg; u64 int_value; } cpc_entry; }; /* Container to hold the CPC details for each CPU */ struct cpc_desc { int num_entries; int version; int cpu_id; int write_cmd_status; int write_cmd_id; struct cpc_register_resource cpc_regs[MAX_CPC_REG_ENT]; struct acpi_psd_package domain_info; struct kobject kobj; }; /* These are indexes into the per-cpu cpc_regs[]. Order is important. */ enum cppc_regs { HIGHEST_PERF, NOMINAL_PERF, LOW_NON_LINEAR_PERF, LOWEST_PERF, GUARANTEED_PERF, DESIRED_PERF, MIN_PERF, MAX_PERF, PERF_REDUC_TOLERANCE, TIME_WINDOW, CTR_WRAP_TIME, REFERENCE_CTR, DELIVERED_CTR, PERF_LIMITED, ENABLE, AUTO_SEL_ENABLE, AUTO_ACT_WINDOW, ENERGY_PERF, REFERENCE_PERF, }; /* * Categorization of registers as described * in the ACPI v.5.1 spec. * XXX: Only filling up ones which are used by governors * today. */ struct cppc_perf_caps { u32 highest_perf; u32 nominal_perf; u32 lowest_perf; }; struct cppc_perf_ctrls { u32 max_perf; u32 min_perf; u32 desired_perf; }; struct cppc_perf_fb_ctrs { u64 reference; u64 delivered; u64 reference_perf; u64 ctr_wrap_time; }; /* Per CPU container for runtime CPPC management. */ struct cppc_cpudata { int cpu; struct cppc_perf_caps perf_caps; struct cppc_perf_ctrls perf_ctrls; struct cppc_perf_fb_ctrs perf_fb_ctrs; struct cpufreq_policy *cur_policy; unsigned int shared_type; cpumask_var_t shared_cpu_map; }; extern int cppc_get_perf_ctrs(int cpu, struct cppc_perf_fb_ctrs *perf_fb_ctrs); extern int cppc_set_perf(int cpu, struct cppc_perf_ctrls *perf_ctrls); extern int cppc_get_perf_caps(int cpu, struct cppc_perf_caps *caps); extern int acpi_get_psd_map(struct cppc_cpudata **); extern unsigned int cppc_get_transition_latency(int cpu); #endif /* _CPPC_ACPI_H*/ 16e77f6dfba96c543e55b6672d5a37e'>scsi/iscsi_if.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
committerLinus Torvalds <torvalds@linux-foundation.org>2017-01-29 13:50:06 -0800
commit39cb2c9a316e77f6dfba96c543e55b6672d5a37e (patch)
tree98fe974ee4e20121253de7f61fc8d01bdb3821c1 /include/scsi/iscsi_if.h
parent2c5d9555d6d937966d79d4c6529a5f7b9206e405 (diff)
drm/i915: Check for NULL i915_vma in intel_unpin_fb_obj()
I've seen this trigger twice now, where the i915_gem_object_to_ggtt() call in intel_unpin_fb_obj() returns NULL, resulting in an oops immediately afterwards as the (inlined) call to i915_vma_unpin_fence() tries to dereference it. It seems to be some race condition where the object is going away at shutdown time, since both times happened when shutting down the X server. The call chains were different: - VT ioctl(KDSETMODE, KD_TEXT): intel_cleanup_plane_fb+0x5b/0xa0 [i915] drm_atomic_helper_cleanup_planes+0x6f/0x90 [drm_kms_helper] intel_atomic_commit_tail+0x749/0xfe0 [i915] intel_atomic_commit+0x3cb/0x4f0 [i915] drm_atomic_commit+0x4b/0x50 [drm] restore_fbdev_mode+0x14c/0x2a0 [drm_kms_helper] drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper] drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper] intel_fbdev_set_par+0x18/0x70 [i915] fb_set_var+0x236/0x460 fbcon_blank+0x30f/0x350 do_unblank_screen+0xd2/0x1a0 vt_ioctl+0x507/0x12a0 tty_ioctl+0x355/0xc30 do_vfs_ioctl+0xa3/0x5e0 SyS_ioctl+0x79/0x90 entry_SYSCALL_64_fastpath+0x13/0x94 - i915 unpin_work workqueue: intel_unpin_work_fn+0x58/0x140 [i915] process_one_work+0x1f1/0x480 worker_thread+0x48/0x4d0 kthread+0x101/0x140 and this patch purely papers over the issue by adding a NULL pointer check and a WARN_ON_ONCE() to avoid the oops that would then generally make the machine unresponsive. Other callers of i915_gem_object_to_ggtt() seem to also check for the returned pointer being NULL and warn about it, so this clearly has happened before in other places. [ Reported it originally to the i915 developers on Jan 8, applying the ugly workaround on my own now after triggering the problem for the second time with no feedback. This is likely to be the same bug reported as https://bugs.freedesktop.org/show_bug.cgi?id=98829 https://bugs.freedesktop.org/show_bug.cgi?id=99134 which has a patch for the underlying problem, but it hasn't gotten to me, so I'm applying the workaround. ] Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'include/scsi/iscsi_if.h')