summaryrefslogtreecommitdiff
path: root/net/xfrm/xfrm_hash.c
diff options
context:
space:
mode:
authorFelix Fietkau <nbd@nbd.name>2017-02-02 10:14:51 +0100
committerKalle Valo <kvalo@qca.qualcomm.com>2017-02-07 11:00:21 +0200
commita34d0a0da1abae46a5f6ebd06fb0ec484ca099d9 (patch)
treecebb096769375fe372b13545da083d4cb6c97100 /net/xfrm/xfrm_hash.c
parentd63ffc45c5d3df15f6fc8c73079458ce4a111995 (diff)
ath9k_hw: check if the chip failed to wake up
In an RFC patch, Sven Eckelmann and Simon Wunderlich reported: "QCA 802.11n chips (especially AR9330/AR9340) sometimes end up in a state in which a read of AR_CFG always returns 0xdeadbeef. This should not happen when when the power_mode of the device is ATH9K_PM_AWAKE." Include the check for the default register state in the existing MAC hang check. Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Kalle Valo <kvalo@qca.qualcomm.com>
Diffstat (limited to 'net/xfrm/xfrm_hash.c')
0 files changed, 0 insertions, 0 deletions
ma to deal with. The case of pages that are really not executable is handled by the existing test for VM_EXEC further down. That leaves us with catching the kernel attempts at executing user pages. We can catch that earlier, even before we do find_vma. It is never valid on powerpc for the kernel to take an exec fault to begin with. So fold that test with the existing test for the kernel faulting on kernel addresses to bail out early. Fixes: 1d18ad026844 ("powerpc/mm: Detect instruction fetch denied and report") Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> Acked-by: Balbir Singh <bsingharora@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Diffstat (limited to 'sound/soc/bcm/Makefile')