NUMA
- Prevent out of bounds access in sysfs numa_node override (Sasha Levin)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWMqyJAAoJEFmIoMA60/r8PXMP/jk33V2VHXmcdAnRpdUM09at
VEosZlsPXmAGwlcbf0y9BMdwu8M8Kd1LAtiTXhbFchoWi3NG8ECPsIlYnQfqVzhm
VEEE4IyMHNfLOgQAf+ZfD5duBjsTDoyl3D2XYa8ugV1jJVs4Vpf2lyWVnwrG32E9
MTf2plaHWtjsser78PA0hQ5w5jJz41acgv9P88mdWmYyr+u2h+G8w+Ro2bLyVsiW
dcSIM7L1R6j9Kp52BqXq31rwHXQIF8v+yDaHNTKR6PzcufyuHKsK2fALa7LSam2P
EJEj7D8FVPFqYs2XRdPiYI+/wjMcM59CETIZ5NtEzjkQvoeTQhLa3iA8LrS4OMNI
JQWbPIHu9dB2Y2fFyeO31kW8+G8zgSKPcdhg9gAdoPspVX387+KHR+aiSMOlGsTu
wCyMQsuQSqcNkKGAyPcaQe6AUaI+3Ri3awuBV3/o20tNq2upPqeljvZa6v3W/Ua+
OSKE9rdRxsMzi1M3sLIDYIg0mD3K+horH52A3cjoOXehhSFX8pucbuk6bvYszPxq
0rPLX7fasbVo/yTLz4RgIk9LK2yxpg7TO1MRQb4byCbBqVJU+7R9JxakqstmJGXv
W0huOvn776rtcpxItfbckyfCsVhqcZ13xP1osjCcFLciSe+eq4dKCY1iH0OyvSOu
S+TkJWdpKEU9L0Tfxjvo
=nuxn
-----END PGP SIGNATURE-----
Merge tag 'pci-v4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI fix from Bjorn Helgaas:
"Sorry for this last-minute update; it's been in -next for quite a
while, but I forgot about it until I started getting ready for the
merge window.
It's small and fixes a way a user could cause a panic via sysfs, so I
think it's worth getting it in v4.3.
NUMA:
- Prevent out of bounds access in sysfs numa_node override (Sasha Levin)"
* tag 'pci-v4.3-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
PCI: Prevent out of bounds access in numa_node override
- Fix omap3 MUSB with DMA caused by driver core changes
- Fix LCD DMA interrupt number for omap1 that did not
get changed for sparse IRQ changes
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWMQmFAAoJEBvUPslcq6Vz0yEP/32OMPYtsJ/zic3zEl7yRTjc
3cTlQlerKrU1oP8Z6eg/Bgvi28yYQlNvuFDYzJ2cLWTbbjoaTjOHYLuoIaScIpM2
El/d/GvGCndET9HS4DMuMplj3OzXMsso38o6h5F6z51xVPtVpjitc36TcMxkeqD/
gQcXRORcvOIvVI7pdjfAm8UMd3r/kF/TsZ5nZhoXHd+UlQJ/boB0r/MmH0VXeI2x
xNCoD9Xl/EaCMLVtWlcXU44CojOhncg5xrfsAsPDBL9aDGijwYRTvtcBatI5Phq/
6fEO/hQhG503nH9Di9ozE+41c5ZjeLk9oGSIvkTjuttpvkvW6CeCLoqW4CuhmHrQ
f8/Wj3TSJ4BBGdbEdPK13t4lXozvMsB1MvxlnoCnCANPIPNTt9DUCs27U4i4YWem
PVLNcR5d7fxSa8mXgKswoRFMimhI9ZZN1MozI2ZwcxqftOgnbNejkmjd9kMwrXen
X4lY1bMlE942zY+gzQvbFKmz6NM5QAAooF29LB/qJdWpLi3wZDU9bUXYGTlPQqC+
JzhfBFgPaEQnZJx+HxOpaWUmxeHyYQWmio2x+xi+0o/MfGnia9FYxtVCuoI8mCiR
fyO4+T8jlnWTZEInm7s45OjsheFbw52PVWJysMWxoyWq0NLa/Af8lKFk/d0/5s8C
/ditVCYYqxwCdWJe17Se
=H1PE
-----END PGP SIGNATURE-----
Merge tag 'omap-for-v4.3/fixes-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
Two omap regression fixes:
- Fix omap3 MUSB with DMA caused by driver core changes
- Fix LCD DMA interrupt number for omap1 that did not
get changed for sparse IRQ changes
* tag 'omap-for-v4.3/fixes-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
usb: musb: omap2430: Fix regression caused by driver core change
ARM: OMAP1: fix incorrect INT_DMA_LCD
Signed-off-by: Olof Johansson <olof@lixom.net>
With devm there is no need to explicitly free irqs on error.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
MSI messages are per-device, so there will never be another "shared"
device in the interrupt chain.
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
There is a few typos in Freescale QorIQ AHCI bindings, This
patch fixes them.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
NCQ feature can't be used due to the erratum A-008473.
This patch disables NCQ as a workaround.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Freescale is renaming the LS2085A SoC to LS2080A.
This patch addresses the same.
Signed-off-by: Tang Yuantian <Yuantian.Tang@freescale.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Commit 073db4a51e ("mtd: fix: avoid race condition when accessing
mtd->usecount") fixed a race condition but due to poor ordering of the
mutex acquisition, introduced a potential deadlock.
The deadlock can occur, for example, when rmmod'ing the m25p80 module, which
will delete one or more MTDs, along with any corresponding mtdblock
devices. This could potentially race with an acquisition of the block
device as follows.
-> blktrans_open()
-> mutex_lock(&dev->lock);
-> mutex_lock(&mtd_table_mutex);
-> del_mtd_device()
-> mutex_lock(&mtd_table_mutex);
-> blktrans_notify_remove() -> del_mtd_blktrans_dev()
-> mutex_lock(&dev->lock);
This is a classic (potential) ABBA deadlock, which can be fixed by
making the A->B ordering consistent everywhere. There was no real
purpose to the ordering in the original patch, AFAIR, so this shouldn't
be a problem. This ordering was actually already present in
del_mtd_blktrans_dev(), for one, where the function tried to ensure that
its caller already held mtd_table_mutex before it acquired &dev->lock:
if (mutex_trylock(&mtd_table_mutex)) {
mutex_unlock(&mtd_table_mutex);
BUG();
}
So, reverse the ordering of acquisition of &dev->lock and &mtd_table_mutex so
we always acquire mtd_table_mutex first.
Snippets of the lockdep output follow:
# modprobe -r m25p80
[ 53.419251]
[ 53.420838] ======================================================
[ 53.427300] [ INFO: possible circular locking dependency detected ]
[ 53.433865] 4.3.0-rc6 #96 Not tainted
[ 53.437686] -------------------------------------------------------
[ 53.444220] modprobe/372 is trying to acquire lock:
[ 53.449320] (&new->lock){+.+...}, at: [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
[ 53.457271]
[ 53.457271] but task is already holding lock:
[ 53.463372] (mtd_table_mutex){+.+.+.}, at: [<c0439994>] del_mtd_device+0x18/0x100
[ 53.471321]
[ 53.471321] which lock already depends on the new lock.
[ 53.471321]
[ 53.479856]
[ 53.479856] the existing dependency chain (in reverse order) is:
[ 53.487660]
-> #1 (mtd_table_mutex){+.+.+.}:
[ 53.492331] [<c043fc5c>] blktrans_open+0x34/0x1a4
[ 53.497879] [<c01afce0>] __blkdev_get+0xc4/0x3b0
[ 53.503364] [<c01b0bb8>] blkdev_get+0x108/0x320
[ 53.508743] [<c01713c0>] do_dentry_open+0x218/0x314
[ 53.514496] [<c0180454>] path_openat+0x4c0/0xf9c
[ 53.519959] [<c0182044>] do_filp_open+0x5c/0xc0
[ 53.525336] [<c0172758>] do_sys_open+0xfc/0x1cc
[ 53.530716] [<c000f740>] ret_fast_syscall+0x0/0x1c
[ 53.536375]
-> #0 (&new->lock){+.+...}:
[ 53.540587] [<c063f124>] mutex_lock_nested+0x38/0x3cc
[ 53.546504] [<c043fe4c>] del_mtd_blktrans_dev+0x80/0xdc
[ 53.552606] [<c043f164>] blktrans_notify_remove+0x7c/0x84
[ 53.558891] [<c04399f0>] del_mtd_device+0x74/0x100
[ 53.564544] [<c043c670>] del_mtd_partitions+0x80/0xc8
[ 53.570451] [<c0439aa0>] mtd_device_unregister+0x24/0x48
[ 53.576637] [<c046ce6c>] spi_drv_remove+0x1c/0x34
[ 53.582207] [<c03de0f0>] __device_release_driver+0x88/0x114
[ 53.588663] [<c03de19c>] device_release_driver+0x20/0x2c
[ 53.594843] [<c03dd9e8>] bus_remove_device+0xd8/0x108
[ 53.600748] [<c03dacc0>] device_del+0x10c/0x210
[ 53.606127] [<c03dadd0>] device_unregister+0xc/0x20
[ 53.611849] [<c046d878>] __unregister+0x10/0x20
[ 53.617211] [<c03da868>] device_for_each_child+0x50/0x7c
[ 53.623387] [<c046eae8>] spi_unregister_master+0x58/0x8c
[ 53.629578] [<c03e12f0>] release_nodes+0x15c/0x1c8
[ 53.635223] [<c03de0f8>] __device_release_driver+0x90/0x114
[ 53.641689] [<c03de900>] driver_detach+0xb4/0xb8
[ 53.647147] [<c03ddc78>] bus_remove_driver+0x4c/0xa0
[ 53.652970] [<c00cab50>] SyS_delete_module+0x11c/0x1e4
[ 53.658976] [<c000f740>] ret_fast_syscall+0x0/0x1c
[ 53.664621]
[ 53.664621] other info that might help us debug this:
[ 53.664621]
[ 53.672979] Possible unsafe locking scenario:
[ 53.672979]
[ 53.679169] CPU0 CPU1
[ 53.683900] ---- ----
[ 53.688633] lock(mtd_table_mutex);
[ 53.692383] lock(&new->lock);
[ 53.698306] lock(mtd_table_mutex);
[ 53.704658] lock(&new->lock);
[ 53.707946]
[ 53.707946] *** DEADLOCK ***
Fixes: 073db4a51e ("mtd: fix: avoid race condition when accessing mtd->usecount")
Reported-by: Felipe Balbi <balbi@ti.com>
Tested-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Cc: <stable@vger.kernel.org>
Arguments passed to list_add_tail were reversed resulting in deletion
of old blob property everytime the new one is added.
Fixes
commit e2f5d2ea47
Author: Daniel Stone <daniels@collabora.com>
Date: Fri May 22 13:34:51 2015 +0100
drm/mode: Add user blob-creation ioctl
Signed-off-by: Maneet Singh <mmaneetsingh@nvidia.com>
[seanpaul tweaked commit subject a little]
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Cc: stable@kernel.org # v4.2
Reviewed-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
This reverts commit 7eb418851f.
This commit is poorly justified, I can find not discusison in email,
and it clearly causes a problem.
If a device which is being recovered fails and is subsequently
re-added to an array, there could easily have been changes to the
array *before* the point where the recovery was up to. So the
recovery must start again from the beginning.
If a spare is being recovered and fails, then when it is re-added we
really should do a bitmap-based recovery up to the recovery-offset,
and then a full recovery from there. Before this reversion, we only
did the "full recovery from there" which is not corect. After this
reversion with will do a full recovery from the start, which is safer
but not ideal.
It will be left to a future patch to arrange the two different styles
of recovery.
Reported-and-tested-by: Nate Dailey <nate.dailey@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: stable@vger.kernel.org (3.14+)
Fixes: 7eb418851f ("md: allow a partially recovered device to be hot-added to an array.")
The size here comes from the user via the ioctl, it is a number between
1-u32max so the addition here could overflow on 32 bit systems.
Fixes: f453ba0460 ('DRM: add mode setting support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Cc: stable@kernel.org # v4.2
Signed-off-by: Dave Airlie <airlied@gmail.com>
- Fix corruption in SWP emulation when STXR fails due to contention
- Fix MMU re-initialisation when resuming from a low-power state
- Fix stack unwinding code to match what ftrace expects
- Fix relocation code in the EFI stub when DRAM base is not 2MB aligned
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJWMlK9AAoJELescNyEwWM0iIcH/AmtOcTR9EZjwxD6szeF1/qg
JuJCW7D0q2TNEw4Ed8TW8W3mSFPBuDWWbypxwpcV7pQZjBKpbDBTd79sdwAbRViZ
mYGgV3NKt6BuChjxxMxnwRXYdF1J38bpFFyXslPue8zmnTkZ5EQ7IR2hMksX2+er
KoPY4Gu0nSTaLD55jFfbtA3pMgoT9gRi+UsMGBseb03TLwAxEmYrtzZNTTMrDqbC
BomRDbE/duOxnhigAMeWb0T/oHY66pZoEjy9YxsSd9HyqZ+l7MbMUkBRkuXj3g5O
9XLsbBWauKp3nGUgBaxu76JovJhbveWaSB4fBF6t5G2WoP47wFjfxhWxpDg6B3Y=
=3Rb/
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Apologies for this being so late, but we've uncovered a few nasty
issues on arm64 which didn't settle down until yesterday and the fixes
all look suitable for 4.3. Of the four patches, three of them are
Cc'd to stable, with the remaining patch fixing an issue that only
took effect during the merge window.
Summary:
- Fix corruption in SWP emulation when STXR fails due to contention
- Fix MMU re-initialisation when resuming from a low-power state
- Fix stack unwinding code to match what ftrace expects
- Fix relocation code in the EFI stub when DRAM base is not 2MB aligned"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64/efi: do not assume DRAM base is aligned to 2 MB
Revert "ARM64: unwind: Fix PC calculation"
arm64: kernel: fix tcr_el1.t0sz restore on systems with extended idmap
arm64: compat: fix stxr failure case in SWP emulation
that it is essential to build systemd.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWMUTSAAoJEKurIx+X31iBgd0QALJD5i2Kqn0UawF0oFLJ7VQx
PFp4SFjhPB1Dsolxh4oR8gdMCHBWnxl3TcOeotAD/6OzkQX2FTaDYO3rV/blTsfy
ZfAJOifio4mforhe5IbiHHUNNjqgOcm6/RLVxuJr8a62Y+M2GMDOQ/gSRhOmGCoe
9Nvbn0FnZisETOvVaYv17AFjLrnuGq2cwozuLyVoIFqOMQV7M6gwK/KH4NDo97nl
ytL8KihNLNrL7ErbUfU3RdmGmTYqlVUE1dk0iFHV/tmfSKpIakjPHP/AKmpEzgLb
+niBzZszCYjvv1f63uHl+/tsq6v3Pv01EHmbrKrcGN2S5/mC2drrnq09Q59BEqoK
AOiZrjYPBWuPIZQOlDbtF+g1xxQX28tGY3Lf1Z2QQnnNqXZqdzGTrzaOe7UHu1xC
cCOyF2MxJrs8Dfbj/ZaciSNW52b7lNaNlj4cCMx3a7JY3C/pj3jYlYZ7qyuZ/rfE
h/AtR9vNWR1vSeS9TBJkn2tu2Xo22ydH9pvMO2HX3s9zV6sMAEw2hhvrvWYoenyF
+KkbfQy3P6FNpGNmVYSZogPkoC5oJaR1o+jWetDX291wH6E8bZOznzWvFt5e1WgH
QhKnuTidYhOvjG0jeZLTmjoQDvZy/I+rIinmA83NLa66vWTY70LjXNYWWTF1V/mz
3WjnDYq9TBiS259cfDdO
=gyuX
-----END PGP SIGNATURE-----
Merge tag 'please-pull-syscalls' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux
Pull ia64 kcmp syscall from Tony Luck:
"Missed adding the kcmp() syscall a long time ago. Now it seems that
it is essential to build systemd"
* tag 'please-pull-syscalls' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
[IA64] Wire up kcmp syscall
After commit 566c09c534 ("raid5: relieve lock contention in get_active_stripe()")
__find_stripe() is called under conf->hash_locks + hash.
But handle_stripe_clean_event() calls remove_hash() under
conf->device_lock.
Under some cirscumstances the hash chain can be circuited,
and we get an infinite loop with disabled interrupts and locked hash
lock in __find_stripe(). This leads to hard lockup on multiple CPUs
and following system crash.
I was able to reproduce this behavior on raid6 over 6 ssd disks.
The devices_handle_discard_safely option should be set to enable trim
support. The following script was used:
for i in `seq 1 32`; do
dd if=/dev/zero of=large$i bs=10M count=100 &
done
neilb: original was against a 3.x kernel. I forward-ported
to 4.3-rc. This verison is suitable for any kernel since
Commit: 59fc630b8b ("RAID5: batch adjacent full stripe write")
(v4.1+). I'll post a version for earlier kernels to stable.
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Fixes: 566c09c534 ("raid5: relieve lock contention in get_active_stripe()")
Signed-off-by: NeilBrown <neilb@suse.com>
Cc: Shaohua Li <shli@kernel.org>
Cc: <stable@vger.kernel.org> # 3.13 - 4.2
Parsing direct subnodes of a mtd device as partitions is unreliable
since the mtd device is also part of its bus subsystem and can contain
bus data in subnodes.
Move ofpart data to a subnode of its own so it is clear which data is
part of the partition layout.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
To avoid conflict with other drivers using subnodes of the mtd device
create only one ofpart-specific node rather than any number of
arbitrary partition subnodes.
Signed-off-by: Michal Suchanek <hramrach@gmail.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Disable VFs if pcibios_enable_sriov() fails, just like we do for other
errors in sriov_enable(). Call pcibios_sriov_disable() if virtfn_add()
fails.
[bhelgaas: changelog, split to separate patch for reviewability]
Fixes: 995df527f3 ("PCI: Add pcibios_sriov_enable() and pcibios_sriov_disable()")
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Per sec 3.3.3.1 of the SR-IOV spec, r1.1, we must allow 1.0s after clearing
VF Enable before reading any field in the SR-IOV Extended Capability.
Wait 1 second before calling pci_iov_set_numvfs(), which reads
PCI_SRIOV_VF_OFFSET and PCI_SRIOV_VF_STRIDE after it sets PCI_SRIOV_NUM_VF.
[bhelgaas: split to separate patch for reviewability, add spec reference]
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Move pcibios_sriov_disable() up so it's defined before a future use.
[bhelgaas: split to separate patch for reviewability]
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Wei Yang <weiyang@linux.vnet.ibm.com>
If virtfn_add() fails, we call virtfn_remove() for any previously added
devices. Remove the devices in reverse order (first-added is
last-removed), which is more natural and doesn't require an additional
variable.
[bhelgaas: changelog, split to separate patch for reviewability]
Signed-off-by: Alexander Duyck <aduyck@mirantis.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Add dt-binding documentation for s2mps15 PMIC device. The s2mps15 device
is similar to s2mps11/14 PMIC device and has 27 LDO and 10 buck regulators.
This also supports RTC and three 32.768KHz clock outputs.
Signed-off-by: Thomas Abraham <thomas.ab@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The commit 54e8827d5f ("mfd: sec-core: Add support for S2MPU02
device") added new MFD child devices for S2MPU02: RTC and clock
provider (the clock provider with new compatible). However support for
these devices was not added to existing drivers (rtc-s5m, clk-s2mps11).
New drivers were not submitted neither.
This means that the name of children devices is completely unused. The
"samsung,s2mpu02-clk" compatible remains undocumented so it is unclear
what is provided by that compatible.
Clean up this by removing unused child devices and undocumented
compatible.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Subsystem specific bindings for the Arizona devices are being factored
out of the MFD binding document into separate documents for each
subsystem. This patch adds a binding document that covers the existing
extcon specific bindings.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Add device tree binding documentation for the Arizona drivers
to the MAINTAINERS file.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Binding documentation has been added in new subsystem specific binding
documents. This patch removes the now duplicate documentation from the
MFD documentation.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Intel Broxton has the same LPSS block than Intel Sunrisepoint so add
Broxton PCI IDs to the list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Intel Broxton has the same LPSS block than Intel Sunrisepoint so add
Broxton ACPI IDs to the list.
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The "jd_active" variable needs to be signed for the error handling to
work.
Fixes: 143e5887ae57 ('mfd: arizona: factor out checking of jack detection state')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Just like other NAND controllers, the NAND READID command only works
in 8bit mode for all versions of BRCMNAND controller.
This patch forces 8bit mode for each NAND CS in brcmnand_init_cs()
before doing nand_scan_ident() to ensure that BRCMNAND controller
is in 8bit mode when NAND READID command is issued.
Signed-off-by: Anup Patel <anup.patel@broadcom.com>
Reviewed-by: Ray Jui <rjui@broadcom.com>
Reviewed-by: Scott Branden <sbranden@broadcom.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Use enum instead of magic numbers for CFG and CFG_EXT bitfields.
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Tested-by: Anup Patel <anup.patel@broadcom.com>
Default the brightness to 2048 and add possibility to override this in
device tree.
Suggested-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Digi 002/003 family uses two ways to transfer MIDI messages. They're
different mechanisms, while it's better to handle the ways in different
ALSA rawmidi character devices because one character device has just a
set of operations.
This commit adds another rawmidi character device for control MIDI port. As
a result, first rawmidi character device is just for MIDI messages
transferred by isochronous packets.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Digi 002/003 family has two types of MIDI port; one is for physical MIDI
port and another is for MIDI control message. The former is transferred in
isochronous packet, and the latter is transferred by asynchronous
transaction. These transmission mechanisms are completely different, while
current ALSA digi00x driver defines a set of operations for them with
several condition statements. As a result, codes for the operation are
messy.
This commit adds a set of MIDI operation for control MIDI ports. In later
commit, it's applied as an operation for ALSA rawmidi character device.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In following commit, new functions and variables are added for operations
of MIDI control port.
This commit is a preparation. Current identifiers are renamed so that they
mean physical MIDI ports.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
rbd requires stable pages, as it performs a crc of the page data before
they are send to the OSDs.
But since kernel 3.9 (patch 1d1d1a7672
"mm: only enforce stable page writes if the backing device requires
it") it is not assumed anymore that block devices require stable pages.
This patch sets the necessary flag to get stable pages back for rbd.
In a ceph installation that provides multiple ext4 formatted rbd
devices "bad crc" messages appeared regularly (ca 1 message every 1-2
minutes on every OSD that provided the data for the rbd) in the
OSD-logs before this patch. After this patch this messages are pretty
much gone (only ca 1-2 / month / OSD).
Cc: stable@vger.kernel.org # 3.9+, needs backporting
Signed-off-by: Ronny Hegewald <Ronny.Hegewald@online.de>
[idryomov@gmail.com: require stable pages only in crc case, changelog]
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
This commit does not change the function behavior.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Addresses should not be prefixed contain '0x' in nodes.
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Signed-off-by: Rob Herring <robh@kernel.org>
This patch marks all the reference to the legacy wakeup bindings
and replaces them with the standard "wakeup-source" property.
All these legacy property are also listed under a separate section in
the generic wakeup-source binding document.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Currently different drivers use multiple forms of annotating devices
that should be set up as wakeup sources for the system.
This patch adds a separate binding document inorder to standardize and
consolidate to use "wakeup-source" boolean property to mark the devices
as wakeup capable.
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>
This patch adds the mfd cell info for axp288 power key device.
Signed-off-by: Borun Fu <borun.fu@linux.intel.com>
Signed-off-by: Fei Yang <fei.yang@intel.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Document a new Device Tree property 'samsung,s2mps11-wrstbi-ground'
indicating that WRSTBI pin of S2MPS13 PMIC is pulled down so
corresponding buck warm reset function should be disabled.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The WRSTBI bit (disabled by default but enabled by bootloader), when
set, is responsible for resetting voltages to default values of
certain bucks on falling edge of Warm Reset Input pin from AP.
However on some boards (with S2MPS13) the pin is pulled down so any
suspend will effectively trigger the reset of bucks supplying the power
to the little and big cores. In the same time when resuming, these bucks
must provide voltage greater or equal to voltage before suspend to match
the frequency chosen by cpufreq. If voltage (default value of voltage
after reset) is lower than one set by cpufreq before suspend, then
system will hang during resuming.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Tested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
There are different revisions of the same chipset. For example S2MPS13 has
more than 2 revisions. They differ slightly in regulator constraints.
Print the revision number to easily find which PMIC is used on the board.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
In the case of a device tree config the code uses the device ID
from the DT entry to check which codec is required but when storing
the ID into struct arizona it was always using the non-DT SPI device
table to get an ID.
This patch changes the code to store the correct ID into struct arizona.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Remove the use of #ifdefs around each case statement of the chip ID
and type validation switches.
We must ensure that the contained code still compiles to nothing if
support for that codec was not built into the kernel, to prevent
creation of link references to missing functions. So the ifdefs are
replaced with a use of the IS_ENABLED() macro.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
The code was using a switch on the code type to execute
one of several mfd_add_devices() calls. We're already
switching on the code type earlier in the function to
select the correct patch function so we can roll selection
of the mfd device table into the same switch.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
If the declared codec type doesn't match the detected type
we issue a log message but carry on registering the device,
so a dev_warn() is appropriate rather than a dev_err()
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Currently runtime_suspend will fully power off the codec if
the jack detection is not enabled. Not all future codecs will
have jack detection so to prepare for these codecs this patch
factors out the check so that it be called as needed in the
existing codec-specific switch cases.
Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
