Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 27 4月, 2016 2 次提交
    • L
      drm/dp/mst: Restore primary hub guid on resume · 9dc0487d
      由 Lyude 提交于 
      Some hubs are forgetful, and end up forgetting whatever GUID we set
previously after we do a suspend/resume cycle. This can lead to
hotplugging breaking (along with probably other things) since the hub
will start sending connection notifications with the wrong GUID. As
such, we need to check on resume whether or not the GUID the hub is
giving us is valid.
Signed-off-by: NLyude <cpaul@redhat.com>
Reviewed-by: NHarry Wentland <harry.wentland@amd.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      9dc0487d
    • C
      drm/dp/mst: Get validated port ref in drm_dp_update_payload_part1() · 263efde3
      由 cpaul@redhat.com 提交于 
      We can thank KASAN for finding this, otherwise I probably would have spent
hours on it. This fixes a somewhat harder to trigger kernel panic, occuring
while enabling MST where the port we were currently updating the payload on
would have all of it's refs dropped before we finished what we were doing:

==================================================================
BUG: KASAN: use-after-free in drm_dp_update_payload_part1+0xb3f/0xdb0 [drm_kms_helper] at addr ffff8800d29de018
Read of size 4 by task Xorg/973
=============================================================================
BUG kmalloc-2048 (Tainted: G    B   W      ): kasan: bad access detected
-----------------------------------------------------------------------------

INFO: Allocated in drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper] age=16477 cpu=0 pid=2175
	___slab_alloc+0x472/0x490
	__slab_alloc+0x20/0x40
	kmem_cache_alloc_trace+0x151/0x190
	drm_dp_add_port+0x1aa/0x1ed0 [drm_kms_helper]
	drm_dp_send_link_address+0x526/0x960 [drm_kms_helper]
	drm_dp_check_and_send_link_address+0x1ac/0x210 [drm_kms_helper]
	drm_dp_mst_link_probe_work+0x77/0xd0 [drm_kms_helper]
	process_one_work+0x562/0x1350
	worker_thread+0xd9/0x1390
	kthread+0x1c5/0x260
	ret_from_fork+0x22/0x40
INFO: Freed in drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper] age=7521 cpu=0 pid=2175
	__slab_free+0x17f/0x2d0
	kfree+0x169/0x180
	drm_dp_free_mst_port+0x50/0x60 [drm_kms_helper]
	drm_dp_destroy_connector_work+0x2b8/0x490 [drm_kms_helper]
	process_one_work+0x562/0x1350
	worker_thread+0xd9/0x1390
	kthread+0x1c5/0x260
	ret_from_fork+0x22/0x40

which on this T460s, would eventually lead to kernel panics in somewhat
random places later in intel_mst_enable_dp() if we got lucky enough.
Signed-off-by: NLyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>
      263efde3
  3. 22 4月, 2016 27 次提交
  5. 21 4月, 2016 11 次提交
    • R
      iommu/arm-smmu: Don't allocate resources for bypass domains · 9800699c
      由 Robin Murphy 提交于 
      Until we get fully plumbed into of_iommu_configure, our default
IOMMU_DOMAIN_DMA domains just bypass translation. Since we achieve that
by leaving the stream table entries set to bypass instead of pointing at
a translation context, the context bank we allocate for the domain is
completely wasted. Context banks are typically a rather limited
resource, so don't hog ones we don't need.
Reported-by: NEric Auger <eric.auger@linaro.org>
Tested-by: NEric Auger <eric.auger@linaro.org>
Signed-off-by: NRobin Murphy <robin.murphy@arm.com>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      9800699c
    • W
      iommu/arm-smmu: Fix stream-match conflict with IOMMU_DOMAIN_DMA · 5f634956
      由 Will Deacon 提交于 
      Commit cbf8277e ("iommu/arm-smmu: Treat IOMMU_DOMAIN_DMA as bypass
for now") ignores requests to attach a device to the default domain
since, without IOMMU-basked DMA ops available everywhere, the default
domain will just lead to unexpected transaction faults being reported.

Unfortunately, the way this was implemented on SMMUv2 causes a
regression with VFIO PCI device passthrough under KVM on AMD Seattle.
On this system, the host controller device is associated with both a
pci_dev *and* a platform_device, and can therefore end up with duplicate
SMR entries, resulting in a stream-match conflict at runtime.

This patch amends the original fix so that attaching to IOMMU_DOMAIN_DMA
is rejected even before configuring the SMRs. This restores the old
behaviour for now, but we'll need to look at handing host controllers
specially when we come to supporting the default domain fully.
Reported-by: NEric Auger <eric.auger@linaro.org>
Tested-by: NEric Auger <eric.auger@linaro.org>
Tested-by: NYang Shi <yang.shi@linaro.org>
Signed-off-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NJoerg Roedel <jroedel@suse.de>
      5f634956
    • L
      drivers/perf: arm-pmu: fix RCU usage on pmu resume from low-power · cbcc72e0
      由 Lorenzo Pieralisi 提交于 
      Commit da4e4f18 ("drivers/perf: arm_pmu: implement CPU_PM notifier")
added code in the arm perf infrastructure that allows the kernel to
save/restore perf counters whenever the CPU enters a low-power
state. The kernel saves/restores the counters for each active event
through the armpmu_{stop/start} ARM pmu API, so that the low-power state
enter/exit cycle is emulated through pmu start/stop operations for each
event in use.

However, calling armpmu_start() for each active event on power up
executes code that requires RCU locking (perf_event_update_userpage())
to be functional, so, given that the core may call the CPU_PM notifiers
while running the idle thread in an quiescent RCU state this is not
allowed as detected through the following splat when kernel is run with
CONFIG_PROVE_LOCKING enabled:

[   49.293286]
[   49.294761] ===============================
[   49.298895] [ INFO: suspicious RCU usage. ]
[   49.303031] 4.6.0-rc3+ #421 Not tainted
[   49.306821] -------------------------------
[   49.310956] include/linux/rcupdate.h:872 rcu_read_lock() used
illegally while idle!
[   49.318530]
[   49.318530] other info that might help us debug this:
[   49.318530]
[   49.326451]
[   49.326451] RCU used illegally from idle CPU!
[   49.326451] rcu_scheduler_active = 1, debug_locks = 0
[   49.337209] RCU used illegally from extended quiescent state!
[   49.342892] 2 locks held by swapper/2/0:
[   49.346768]  #0:  (cpu_pm_notifier_lock){......}, at:
[<ffffff8008163c28>] cpu_pm_exit+0x18/0x80
[   49.355492]  #1:  (rcu_read_lock){......}, at: [<ffffff800816dc38>]
perf_event_update_userpage+0x0/0x260

This patch wraps the armpmu_start() call (that indirectly calls
perf_event_update_userpage()) on CPU_PM notifier power state exit (or
failed entry) within the RCU_NONIDLE() macro so that the RCU subsystem
is made aware the calling cpu is not idle from an RCU perspective for
the armpmu_start() call duration, therefore fixing the issue.

Fixes: da4e4f18 ("drivers/perf: arm_pmu: implement CPU_PM notifier")
Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reported-by: NJames Morse <james.morse@arm.com>
Suggested-by: NKevin Hilman <khilman@baylibre.com>
Cc: Ashwin Chaugule <ashwin.chaugule@linaro.org>
Cc: Kevin Hilman <khilman@baylibre.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Acked-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
Acked-by: NWill Deacon <will.deacon@arm.com>
Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      cbcc72e0
    • L
      drm/etnaviv: don't move linear memory window on 3D cores without MC2.0 · 2144fff7
      由 Lucas Stach 提交于 
      On cores with MC1.0 the memory window offset is not properly respected
by all engines in the core, leading to different views of the memory
if the offset in non-zero. This causes relocs for those engines to be
wrong and might lead to other subtile problems.

Rather than trying to work around this, just disable the linear memory
window offset for those cores.
Suggested-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      2144fff7
    • J
      thermal: fix Mediatek thermal controller build · a6f4850d
      由 Johannes Berg 提交于 
      At least with CONFIG_COMPILE_TEST, there's no reason to assume
that CONFIG_RESET_CONTROLLER is set, but the code for this
controller requires it since it calls device_reset().

Make CONFIG_MTK_THERMAL properly depend on CONFIG_RESET_CONTROLLER.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      a6f4850d
    • W
      thermal: consistently use int for trip temp · 1d0fd42f
      由 Wei Ni 提交于 
      The commit 17e8351a consistently use int for temperature,
however it missed a few in trip temperature and thermal_core.

In current codes, the trip->temperature used "unsigned long"
and zone->temperature used"int", if the temperature is negative
value, it will get wrong result when compare temperature with
trip temperature.

This patch can fix it.
Signed-off-by: NWei Ni <wni@nvidia.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      1d0fd42f
    • R
      thermal: fix mtk_thermal build dependency · 62e14f6f
      由 Randy Dunlap 提交于 
      Fix build errors when MTK_THERMAL=y and NVMEM=m by preventing that
Kconfig combination.

drivers/built-in.o: In function `mtk_thermal_probe':
mtk_thermal.c:(.text+0xffa8f): undefined reference to `nvmem_cell_get'
mtk_thermal.c:(.text+0xffabe): undefined reference to `nvmem_cell_read'
mtk_thermal.c:(.text+0xffac9): undefined reference to `nvmem_cell_put'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: <linux-pm@vger.kernel.org>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Hanyi Wu <hanyi.wu@mediatek.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      62e14f6f
    • R
      thermal: minor mtk_thermal.c cleanups · 9ebfb4e0
      由 Randy Dunlap 提交于 
      Trivial cleanups:
- delete one duplicate #include
- end email address with closing '>'
Signed-off-by: NRandy Dunlap <rdunlap@infradead.org>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Hanyi Wu <hanyi.wu@mediatek.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      9ebfb4e0
    • J
      thermal: power_allocator: req_range multiplication should be a 64 bit type · f9d03814
      由 Javi Merino 提交于 
      req_range is declared as a u64 to cope with overflows in the
multiplication of two u32.  As both req_power and power_range are u32,
we need to make sure the multiplication is done with u64 types.
Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: NJavi Merino <javi.merino@arm.com>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      f9d03814
    • J
      thermal: of: add __init attribute · c0ff8aaa
      由 Julia Lawall 提交于 
      Add __init attribute on a function that is only called from other __init
functions and that is not inlined, at least with gcc version 4.8.4 on an
x86 machine with allyesconfig.  Currently, the function is put in the
.text.unlikely segment.  Declaring it as __init will cause it to be put in
the .init.text and to disappear after initialization.

The result of objdump -x on the function before the change is as follows:

0000000000000086 l     F .text.unlikely 0000000000000739 thermal_of_build_thermal_zone

And after the change it is as follows:

0000000000000000 l     F .init.text	0000000000000734 thermal_of_build_thermal_zone

Done with the help of Coccinelle.  The semantic patch checks for local
static non-init functions that are called from an __init function and are
not called from any other function.
Signed-off-by: NJulia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: NEduardo Valentin <edubezval@gmail.com>
      c0ff8aaa
    • D
      Input: twl4030-vibra - do not reparent to grandparent · dcc75971
      由 Dmitry Torokhov 提交于 
      For devm-managed input devices we should not modify input device's parent,
otherwise automatic release of resources will not work properly.
Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      dcc75971