| Age | Commit message (Collapse) | Author |
|---|
|
* p-ti-linux-3.14.y-common:
remoteproc/pruss: fix shutdown for manually booted PRU cores
remoteproc/pruss: fix the cleanup path in pru_rproc_probe()
iommu/omap: Fix a sleeping function invocation in atomic context bug
remoteproc/pruss: use match data instead of platform data for PRUs
remoteproc/pruss: fix a crash with platform_device_unregister
iommu/omap: Fix a minor typo in debugfs output
Change-Id: Ic9f05343bab23728c20d6b2f16a516fa4e7ee49e
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common
* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
remoteproc/pruss: fix shutdown for manually booted PRU cores
remoteproc/pruss: fix the cleanup path in pru_rproc_probe()
iommu/omap: Fix a sleeping function invocation in atomic context bug
remoteproc/pruss: use match data instead of platform data for PRUs
remoteproc/pruss: fix a crash with platform_device_unregister
iommu/omap: Fix a minor typo in debugfs output
Change-Id: I320e320a4da0b4a44e2eecd60dc4f85b559b3c5b
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
* p-ti-linux-3.14.y-common:
usb: dwc3: debugfs: dual role switch through debugfs entries
ARM: DRA7: dts: Add coprocessor nodes for iva
UAPI: Increasing the max FRAME number to 128.
gpio: mcp23s08: Set initial direction and value from DT
firmware: Load VPDMA firmware from kernel
drivers: power: Introduce TI coprocessor driver
Change-Id: I40081e26ca7b53359f832e76371aaea5b5c08878
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
ti-linux-3.14.y
TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y
* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
remoteproc/pruss: fix shutdown for manually booted PRU cores
remoteproc/pruss: fix the cleanup path in pru_rproc_probe()
iommu/omap: Fix a sleeping function invocation in atomic context bug
remoteproc/pruss: use match data instead of platform data for PRUs
remoteproc/pruss: fix a crash with platform_device_unregister
iommu/omap: Fix a minor typo in debugfs output
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
|
|
rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes
couple of fixes for the OMAP IOMMU driver.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
iommu/omap: Fix a sleeping function invocation in atomic context bug
iommu/omap: Fix a minor typo in debugfs output
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
dual role switch through debugfs entries
usage:
1) mount debugfs
# mount -t debugfs debugfs /mnt
2) To switch usb1 to device/host mode
# echo "device" > /mnt/48890000.dwc3/mode
# echo "host" > /mnt/48890000.dwc3/mode
3) To switch usb2 to device/host mode
# echo "device" > /mnt/488d0000.dwc3/mode
# echo "host" > /mnt/488d0000.dwc3/mode
To switch to device mode: make sure previous mode is host.
To switch to host mode: make sure previous mode is device
Change-Id: Ie7f637df45b215b966e9eb17637907a74278aa7e
Signed-off-by: Ravi Babu <ravibabu@ti.com>
|
|
p-ti-linux-3.14.y-common
|
|
rpmsg-ti-linux-3.14.y
Pull in the updated remoteproc feature branch that includes various
bug fixes for the PRUSS remoteproc driver. The fixes are agnostic
of the SoC.
* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
remoteproc/pruss: fix shutdown for manually booted PRU cores
remoteproc/pruss: fix the cleanup path in pru_rproc_probe()
remoteproc/pruss: use match data instead of platform data for PRUs
remoteproc/pruss: fix a crash with platform_device_unregister
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
rproc-linux-3.14.y
Merge in the updated iommu feature branch into remoteproc tree to
pull in couple of OMAP IOMMU fixes.
* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
iommu/omap: Fix a sleeping function invocation in atomic context bug
iommu/omap: Fix a minor typo in debugfs output
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
The remoteproc infrastructure auto-boots the processors that have
support for virtio transports. The remoteproc virtio layer also
handles the shutdown for such remoteproc devices, but not for
processors booted outside the remoteproc virtio layer.
The current PRU remoteproc driver also provides support to manually
boot a PRU processor if there are no virtio devices associated with
the processor (standalone functionality without any communication
with the MPU, usually used in a configuration where one of the PRU
cores is used in a slave-mode and complements the functionality
implemented on the other PRU core). The manual boot is done during
the probe of the PRU rproc driver, but it isn't handling the shutdown
of the PRU processor, so the same has been fixed.
This also fixes an issue with the module reference count of the PRUSS
remoteproc module. The rproc_boot() function holds a reference count
to the module implementing the driver for the corresponding remoteproc
device. The PRUSS remoteproc module implements two platform drivers -
one for the PRUSS subsystem, and the other to deal with the individual
PRU cores, and as such the module reference count module is incremented
for every booted processor, and is decremented properly only when the
corresponding processor is shutdown. Without the fix, the reference
count is never decremented when the PRU rproc device or the parent
PRUSS subsystem device is unbound from their corresponding drivers.
NOTE:
The rmmod of the PRUSS remoteproc module can only succeed when the
PRU/PRUSS devices are unbound from their drivers, if there were any
manually booted PRU cores. Ideally, the boot would have to be
implemented in a different layer to avoid this issue.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
The PRU remoteproc driver can manually boot a processor if
the corresponding firmware doesn't support virtio devices.
However, the current cleanup code doesn't undo the operations
performed by rproc_add() in case the manual boot fails. A
successful rproc_add() requires the corresponding rproc_del()
to be called during cleanup, so fix the same.
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
GPIO framework does not allow to set a set of gpios is one shot.
Even the gpio_request_array iterates over each entry and sets up gpio
lines one by one.
For some devices (e.g. FPDlink deserializer), if the gpios are used as
to drive some of the control pins, each combination of the control
pins define a specific behavior, some other combination may lead to
inconsistent state, so it is needed to set all of the gpio pins in one shot.
This can be achieved by reading the initial directions and values
from device tree. Add support for reading the device tree properties
and initialize the gpio pins as specified by the DT.
Change-Id: I54d01396dc1b345c9423e3f1976e3cc14d1e6b6e
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
|
|
Created a Kconfig option to load the VPDMA firmware from kernel itself.
When enabled, VIP and VPE modules need not wai for user space to
load the VPDMA firmware
This will help in early initialization of VIP/VPE in bootup sequence.
Change-Id: Id716cb22decf0d5690dac12a5ea2888e29dc0ebd
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
|
|
* p-ti-linux-3.14.y-common: (97 commits)
media: ti-vpe: vpe: Add RGB565 and RGB5551 support
media: ti-vpe: vpe: Post next descriptor only for list complete IRQ
media: ti-vpe: vpe: Setup srcdst parameters in streamON
omapdrm: Expose the OMAP pre-multiplied alpha property through DRM
omapdrm: Expose the OMAP global alpha property through DRM
ti_fragments: audio_display: enable BACKLIGHT_GPIO and PANEL_DPI
ti_fragments: audio_display: clean up
arm/dts: am57xx-evm: Add LCD support
backlight: gpio-backlight: Add DT support
arm/dts: dra7xx: fix display compatible strings
OMAPDSS: add missing 'omapdss' prefixes to display drivers
OMAPDSS: add dra7-dss to dt conversion list
Linux 3.14.31
md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.
mm: get rid of radix tree gfp mask for pagecache_get_page
mm: page_alloc: reduce cost of the fair zone allocation policy
mm: page_alloc: abort fair zone allocation policy when remotes nodes are encountered
mm: vmscan: only update per-cpu thresholds for online CPU
mm: move zone->pages_scanned into a vmstat counter
mm: rearrange zone fields into read-only, page alloc, statistics and page reclaim lines
...
Change-Id: Ib0c33383880f80ba4468e919de46bbeaf42b1bd5
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
|
|
|
|
The kzalloc function in the omap_iommu_attach_init() function is
invoked with GFP_KERNEL flag, but the function is called with a
spinlock held (atomic context). This throws up the following warning
with CONFIG_DEBUG_ATOMIC_SLEEP enabled:
remoteproc0: powering up 58820000.ipu
remoteproc0: Booting fw image dra7-ipu1-fw.xem4, size 6115639
BUG: sleeping function called from invalid context at mm/slab.c:2967
in_atomic(): 1, irqs_disabled(): 0, pid: 65, name: kworker/0:1
CPU: 0 PID: 65 Comm: kworker/0:1 Not tainted 3.14.30-00284-g46d15f7 #11
Workqueue: events request_firmware_work_func
Backtrace:
[<c0012110>] (dump_backtrace) from [<c00122ac>] (show_stack+0x18/0x1c)
r6:000080d0 r5:c0900e00 r4:00000000 r3:ec21a000
[<c0012294>] (show_stack) from [<c0612974>] (dump_stack+0x84/0xb8)
[<c06128f0>] (dump_stack) from [<c0061ea0>] (__might_sleep+0xcc/0xf8)
r4:ec21a000 r3:40000013
[<c0061dd4>] (__might_sleep) from [<c00ef888>] (__kmalloc+0xe4/0x124)
r5:ec000080 r4:000080d0
[<c00ef7a4>] (__kmalloc) from [<c0506164>] (omap_iommu_attach_dev+0xd0/0x3e0)
r7:ec6f6800 r6:eb400994 r5:00000000 r4:ec25ad40
[<c0506094>] (omap_iommu_attach_dev) from [<c0503f84>] (iommu_attach_device+0x20/0x2c)
r10:ec247810 r9:eb40098c r8:ec6f6840 r7:eb400828 r6:eb400994 r5:00000000
r4:eb400800
[<c0503f64>] (iommu_attach_device) from [<c0509ff8>] (rproc_boot+0x27c/0x4d4)
[<c0509d7c>] (rproc_boot) from [<c050ad84>] (rproc_virtio_find_vqs+0x1a8/0x204)
r10:eb16e410 r9:bf001908 r8:ec21bca0 r7:ec21bc8c r6:ec21bc94 r5:ec21bc9c
r4:00000002
....
....
[<c0059e0c>] (kthread) from [<c000eb18>] (ret_from_fork+0x14/0x3c)
r7:00000000 r6:00000000 r5:c0059e0c r4:ec1ecf40
omap-iommu 58882000.mmu: 58882000.mmu: version 2.1
remoteproc0: remote processor 58820000.ipu is now up
Fix the same by using the appropriate GFP_ATOMIC flag. Note that
the fix does not convert the spinlock into a mutex, even though the
attach is done usually in a process context. This is done to keep the
IOMMU API generic and allow them to be called from any context.
Fixes: 6636390de ("iommu/omap: add support to program multiple iommus")
Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
|
|
VPE hardware can generate output in RGB565 or in RGB5551 format.
Add these formats in the supprorted format list for CAPTURE stream.
Also, for RGB5551 format, the alpha component is not processed,
so the alpha value is taken from the default color.
Set the default color to make alpha component full when the dst
format is of RGB colorspace.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
vpe_irq checks for the possible interrupt sources and prints the
errors for the DEI_ERROR and DS_UV interrupts. But it also post the
next descriptor list irrespective of whichever interrupt has occured.
Because of this, driver may release the buffers even before DMA is complete
and also schedule next descriptor list.
Fix this by _actually_ handling the IRQ only when ListComplete IRQ occurs.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
For deinterlacing operation, each operation needs 2 fields in the history.
This is achieved by holding three buffers in ctx->src_vbs[0,1,2] (f,f-1,f-2)
This is achieved by using the ctx->sequence which gets reset via the s_fmt ioctl.
These buffers are dequeded in stream OFF by calling free_vbs()
But the corresponding references aren't removed anywhere.
When application tries to stream ON and OFF continuously, s_fmt ioctl won't
be called and it won't setup the srcdst parameters.
Setting source/destination parameters in stream ON ioctl would make sure that
the context is re-initialized before it is being used by the driver.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
Added support for pre-multiplied alpha changes through DRM plane properties
Signed-off-by: alaganraj <alaganraj.s@ti.com>
[Reworked and made the pre_mult_alpha an enum property]
Signed-off-by: Somnath Mukherjee <somnath@ti.com>
[tomi.valkeinen@ti.com: removed unneeded enum]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
Added support for global alpha changes through DRM plane properties
Signed-off-by: alaganraj <alaganraj.s@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
[ upstream commit 9a6adb339e5d1827da5e8b2459b12863d72ed3e7 ]
Signed-off-by: Denis Carikli <denis@eukrea.com>
Acked-by: Jingoo Han <jg1.han@samsung.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
OMAP's display driver's compatible strings need 'omapdss' prefix, which
was missing for some drivers. Add the prefix.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
Add 'ti,dra7-dss' compatible string to DSS's boot init system.
Without this, the display driver's compatible string matching does not
work properly.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
|
|
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into ti-linux-3.14.y
This is the 3.14.31 stable release
* tag 'v3.14.31' of http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable: (77 commits)
Linux 3.14.31
md/raid5: fetch_block must fetch all the blocks handle_stripe_dirtying wants.
mm: get rid of radix tree gfp mask for pagecache_get_page
mm: page_alloc: reduce cost of the fair zone allocation policy
mm: page_alloc: abort fair zone allocation policy when remotes nodes are encountered
mm: vmscan: only update per-cpu thresholds for online CPU
mm: move zone->pages_scanned into a vmstat counter
mm: rearrange zone fields into read-only, page alloc, statistics and page reclaim lines
mm: pagemap: avoid unnecessary overhead when tracepoints are deactivated
memcg, vmscan: Fix forced scan of anonymous pages
vmalloc: use rcu list iterator to reduce vmap_area_lock contention
mm: make copy_pte_range static again
mm, thp: only collapse hugepages to nodes with affinity for zone_reclaim_mode
mm/memory.c: use entry = ACCESS_ONCE(*pte) in handle_pte_fault()
shmem: fix init_page_accessed use to stop !PageLRU bug
mm: avoid unnecessary atomic operations during end_page_writeback()
mm: non-atomically mark page accessed during page cache allocation where possible
fs: buffer: do not use unnecessary atomic operations when discarding buffers
mm: do not use unnecessary atomic operations when adding pages to the LRU
mm: do not use atomic operations when releasing pages
...
Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
|
|
commit 108cef3aa41669610e1836fe638812dd067d72de upstream.
It is critical that fetch_block() and handle_stripe_dirtying()
are consistent in their analysis of what needs to be loaded.
Otherwise raid5 can wait forever for a block that won't be loaded.
Currently when writing to a RAID5 that is resyncing, to a location
beyond the resync offset, handle_stripe_dirtying chooses a
reconstruct-write cycle, but fetch_block() assumes a
read-modify-write, and a lockup can happen.
So treat that case just like RAID6, just as we do in
handle_stripe_dirtying. RAID6 always does reconstruct-write.
This bug was introduced when the behaviour of handle_stripe_dirtying
was changed in 3.7, so the patch is suitable for any kernel since,
though it will need careful merging for some versions.
Cc: stable@vger.kernel.org (v3.7+)
Fixes: a7854487cd7128a30a7f4f5259de9f67d5efb95f
Reported-by: Henry Cai <henryplusplus@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[Not needed in newer kernels due to refactoring fixing this issue.]
With 3.14.29 (and older kernels) some of my I.mx6 Sabrelite boards were
crashing with the following oops:
sdhci: Secure Digital Host Controller Interface driver
sdhci: Copyright(c) Pierre Ossman
sdhci-pltfm: SDHCI platform and OF driver helper
sdhci-esdhc-imx 2198000.usdhc: could not get ultra high speed state, work on normal mode
mmc0: no vqmmc regulator found
mmc0: SDHCI controller on 2198000.usdhc [2198000.usdhc] using ADMA
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c0004000
[00000000] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.29 #1
task: c08a7120 ti: c089c000 task.ti: c089c000
PC is at wake_up_process+0x8/0x40
LR is at sdhci_irq+0x748/0x9c4
Full boot log can be found at:
http://storage.kernelci.org/stable/v3.14.29/arm-multi_v7_defconfig/lab-collabora/boot-imx6q-sabrelite.html
This happens if the sdhci interrupt status contains SDHCI_INT_CARD_INT,
while the sdio irq was never setup. This patch fixes that in a minimal
way by checking if the sdio irq was setup.
In more recent kernels this bug went away due to refactoring done by
Russel King. So an alternative (potentially better?) fix for this patch
is to cherrypick the following patches from a recent kernel:
18258f7239a6 - genirq: Provide synchronize_hardirq()
bf3b5ec66bd0 - mmc: sdio_irq: rework sdio irq handling
41005003bcaf - mmc: sdhci: clean up interrupt handling
781e989cf593 - mmc: sdhci: convert to new SDIO IRQ handling
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Tyler Baker <tyler.baker@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c4dc304677e8d566572c4738d95c48be150c6606 upstream.
Commit f95499c3030f ("n_tty: Don't wait for buffer work in read() loop")
introduces a race window where a pty master can be signalled that the pty
slave was closed before all the data that the slave wrote is delivered.
Commit f8747d4a466a ("tty: Fix pty master read() after slave closes") fixed the
problem in case of n_tty_read, but the problem still exists for n_tty_poll.
This can be seen by running 'for ((i=0; i<100;i++));do ./test.py ;done'
where test.py is:
import os, select, pty
(pid, pty_fd) = pty.fork()
if pid == 0:
os.write(1, 'This string should be received by parent')
else:
poller = select.epoll()
poller.register( pty_fd, select.EPOLLIN )
ready = poller.poll( 1 * 1000 )
for fd, events in ready:
if not events & select.EPOLLIN:
print 'missed POLLIN event'
else:
print os.read(fd, 100)
poller.close()
The string from the slave is missed several times.
This patch takes the same approach as the fix for read and special cases
this condition for poll.
Tested on 3.16.
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Cc: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 7c4f56070fde2367766fa1fb04852599b5e1ad35 upstream.
The 'max' size passed into the function is measured in number of bits
(KEY_MAX, LED_MAX, etc) so we need to convert it accordingly before trying
to copy the data out, otherwise we will try copying too much and end up
with up with a page fault.
Reported-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3b9d35d744bb5139f9fed57f38c019bb8c7d351c upstream.
This was not noticed for many years. Affects operation if
md raid is used a backing device for DRBD.
CC: stable@kernel.org # v3.2+
Signed-off-by: Philipp Reisner <philipp.reisner@linbit.com>
Signed-off-by: Lars Ellenberg <lars.ellenberg@linbit.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.
This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.
This commit broke on x86 PV because entries in the generic SWIOTLB are
indexed using (pseudo-)physical address not DMA address and these are
not the same in a x86 PV guest.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
DMA mapped IO should be unmapped on the error path in probe() and
unconditionally on remove().
Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.
EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.
Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.
Fix this by putting the inversion at the correct position again.
Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Reported-by: GP Orcullo <kinsamanka@gmail.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Tobias Jakobi <tjakobi@math.uni-bielefeld.de>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9b1087aa5e86448fe6ad40a58964e35f3ba423d5 upstream.
When changing flags in the CAN drivers ctrlmode the provided new content has to
be checked whether the bits are allowed to be changed. The bits that are to be
changed are given as a bitfield in cm->mask. Therefore checking against
cm->flags is wrong as the content can hold any kind of values.
The iproute2 tool sets the bits in cm->mask and cm->flags depending on the
detected command line options. To be robust against bogus user space
applications additionally sanitize the provided flags with the provided mask.
Cc: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.
As a minimal fix for stable, don't use window 13. A full fix will
follow later.
Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream.
Introduce a new variable to count the number of allocated migration
structures. The existing variable cache->nr_migrations became
overloaded. It was used to:
i) track of the number of migrations in flight for the purposes of
quiescing during suspend.
ii) to estimate the amount of background IO occuring.
Recent discard changes meant that REQ_DISCARD bios are processed with
a migration. Discards are not background IO so nr_migrations was not
incremented. However this could cause quiescing to complete early.
(i) is now handled with a new variable cache->nr_allocated_migrations.
cache->nr_migrations has been renamed cache->nr_io_migrations.
cleanup_migration() is now called free_io_migration(), since it
decrements that variable.
Also, remove the unused cache->next_migration variable that got replaced
with with prealloc_structs a while ago.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream.
If a DM table is reloaded with an inactive table when the device is not
suspended (normal procedure for LVM2), then there will be two dm-bufio
objects that can diverge. This can lead to a situation where the
inactive table uses bufio to read metadata at the same time the active
table writes metadata -- resulting in the inactive table having stale
metadata buffers once it is promoted to the active table slot.
Fix this by using reference counting and a global list of cache metadata
objects to ensure there is only one metadata object per metadata device.
Signed-off-by: Joe Thornber <ejt@redhat.com>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream.
Fixes a race condition in abort handling that was injected
when multiple interrupt support was added. When only a single
interrupt is present, the adapter guarantees it will send
responses for aborted commands prior to the response for the
abort command itself. With multiple interrupts, these responses
generally come back on different interrupts, so we need to
ensure the abort thread waits until the aborted command is
complete so we don't perform a double completion. This race
condition was being hit frequently in environments which
were triggering command timeouts, which was resulting in
a double completion causing a kernel oops.
Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Reviewed-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>
Tested-by: Wendy Xiong <wenxiong@linux.vnet.ibm.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.
[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]
[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann <andihartmann@freenet.de>
Tested-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f331a859e0ee5a898c1f47596eddad4c4f02d657 upstream.
Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset. We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset. This is too much to ask for some devices.
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit d8a74e186949e1a2c2f1309212478b0659bf9225 upstream.
This was accidently lost in 76a0df859def.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 5615f890bc6babdc2998dec62f3552326d06eb7b upstream.
This adds a quirks list to fix stability problems with
certain SI boards.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 4369a69ec6ab86821352bd753c68af5880f87956 upstream.
Disable dpm on certain problematic boards rather than
disabling dpm for the entire chip family since most
boards work fine.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
https://bugzilla.kernel.org/show_bug.cgi?id=83731
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 226e5ae9e5f9108beb0bde4ac69f68fe6210fed9 upstream.
If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
if the mutex debugging is enabled which introduces a race in our
mutex_is_locked_by() - i.e. we may inspect the old owner value before it
is acquired by the new task.
This is the root cause of this error:
# diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
# index 5cf6731..3ef3736 100644
# --- a/kernel/locking/mutex-debug.c
# +++ b/kernel/locking/mutex-debug.c
# @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
# DEBUG_LOCKS_WARN_ON(lock->owner != current);
#
# DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
# - mutex_clear_owner(lock);
# }
#
# /*
# * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
# * mutexes so that we can do it here after we've verified state.
# */
# + mutex_clear_owner(lock);
# atomic_set(&lock->count, 1);
# }
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit ce7514526742c0898b837d4395f515b79dfb5a12 upstream.
It is possible for ata_sff_flush_pio_task() to set ap->hsm_task_state to
HSM_ST_IDLE in between the time __ata_sff_port_intr() checks for HSM_ST_IDLE
and before it calls ata_sff_hsm_move() causing ata_sff_hsm_move() to BUG().
This problem is hard to reproduce making this patch hard to verify, but this
fix will prevent the race.
I have not been able to reproduce the problem, but here is a crash dump from
a 2.6.32 kernel.
On examining the ata port's state, its hsm_task_state field has a value of HSM_ST_IDLE:
crash> struct ata_port.hsm_task_state ffff881c1121c000
hsm_task_state = 0
Normally, this should not be possible as ata_sff_hsm_move() was called from ata_sff_host_intr(),
which checks hsm_task_state and won't call ata_sff_hsm_move() if it has a HSM_ST_IDLE value.
PID: 11053 TASK: ffff8816e846cae0 CPU: 0 COMMAND: "sshd"
#0 [ffff88008ba03960] machine_kexec at ffffffff81038f3b
#1 [ffff88008ba039c0] crash_kexec at ffffffff810c5d92
#2 [ffff88008ba03a90] oops_end at ffffffff8152b510
#3 [ffff88008ba03ac0] die at ffffffff81010e0b
#4 [ffff88008ba03af0] do_trap at ffffffff8152ad74
#5 [ffff88008ba03b50] do_invalid_op at ffffffff8100cf95
#6 [ffff88008ba03bf0] invalid_op at ffffffff8100bf9b
[exception RIP: ata_sff_hsm_move+317]
RIP: ffffffff813a77ad RSP: ffff88008ba03ca0 RFLAGS: 00010097
RAX: 0000000000000000 RBX: ffff881c1121dc60 RCX: 0000000000000000
RDX: ffff881c1121dd10 RSI: ffff881c1121dc60 RDI: ffff881c1121c000
RBP: ffff88008ba03d00 R8: 0000000000000000 R9: 000000000000002e
R10: 000000000001003f R11: 000000000000009b R12: ffff881c1121c000
R13: 0000000000000000 R14: 0000000000000050 R15: ffff881c1121dd78
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#7 [ffff88008ba03d08] ata_sff_host_intr at ffffffff813a7fbd
#8 [ffff88008ba03d38] ata_sff_interrupt at ffffffff813a821e
#9 [ffff88008ba03d78] handle_IRQ_event at ffffffff810e6ec0
|
|
commit db93facfb0ef542aa5d8079e47580b3e669a4d82 upstream.
This patch is to fix two deadlock cases.
Deadlock 1:
CPU #1
pinctrl_register-> pinctrl_get ->
create_pinctrl
(Holding lock pinctrl_maps_mutex)
-> get_pinctrl_dev_from_devname
(Trying to acquire lock pinctrldev_list_mutex)
CPU #0
pinctrl_unregister
(Holding lock pinctrldev_list_mutex)
-> pinctrl_put ->> pinctrl_free ->
pinctrl_dt_free_maps -> pinctrl_unregister_map
(Trying to acquire lock pinctrl_maps_mutex)
Simply to say
CPU#1 is holding lock A and trying to acquire lock B,
CPU#0 is holding lock B and trying to acquire lock A.
Deadlock 2:
CPU #3
pinctrl_register-> pinctrl_get ->
create_pinctrl
(Holding lock pinctrl_maps_mutex)
-> get_pinctrl_dev_from_devname
(Trying to acquire lock pinctrldev_list_mutex)
CPU #2
pinctrl_unregister
(Holding lock pctldev->mutex)
-> pinctrl_put ->> pinctrl_free ->
pinctrl_dt_free_maps -> pinctrl_unregister_map
(Trying to acquire lock pinctrl_maps_mutex)
CPU #0
tegra_gpio_request
(Holding lock pinctrldev_list_mutex)
-> pinctrl_get_device_gpio_range
(Trying to acquire lock pctldev->mutex)
Simply to say
CPU#3 is holding lock A and trying to acquire lock D,
CPU#2 is holding lock B and trying to acquire lock A,
CPU#0 is holding lock D and trying to acquire lock B.
Signed-off-by: Jim Lin <jilin@nvidia.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 0915e6feb38de8d3601819992a5bd050201a56fa upstream.
The gpio device attributes were never destroyed when the gpio was
unexported (or on export failures).
Use device_create_with_groups() to create the default device attributes
of the gpio class device. Note that this also fixes the
attribute-creation race with userspace for these attributes.
Remove contingent attributes in export error path and on unexport.
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 121b6a79955a3a3fd7bbb9b8cb88d5b9dad6283d upstream.
The gpio-chip device attributes were never destroyed when the device was
removed.
Fix by using device_create_with_groups() to create the device attributes
of the chip class device.
Note that this also fixes the attribute-creation race with userspace.
Fixes: d8f388d8dc8d ("gpio: sysfs interface")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y
TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y
* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
ti_config_fragments/baseport.cfg: Add IOdelay configuration driver
ARM: dts: dra7: Add iodelay module
pinctrl: Introduce TI IOdelay configuration driver
pinctrl: bindings: pinctrl: Add support for TI's IODelay configuration
pinctrl: dra: dt-bindings: Add virtual mode configuration option
Conflicts:
include/dt-bindings/pinctrl/dra.h
Signed-off-by: Dan Murphy <DMurphy@ti.com>
|
