When detaching contexts, we may still have interrupts in the system
which are yet to be delivered to any CPU and be acked in the PSL.
This can result in a subsequent unrelated process getting an spurious
IRQ or an interrupt for a non-existent context.
This polls the PSL to ensure that the PSL is clear of IRQs for the
detached context, before removing the context from the idr.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Keep IRQ mappings on context teardown. This won't leak IRQs as if we
allocate the mapping again, the generic code will give the same
mapping used last time.
Doing this works around a race in the generic code. Masking the
interrupt introduces a race which can crash the kernel or result in
IRQ that is never EOIed. The lost of EOI results in all subsequent
mappings to the same HW IRQ never receiving an interrupt.
We've seen this race with cxl test cases which are doing heavy context
startup and teardown at the same time as heavy interrupt load.
A fix to the generic code is being investigated also.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: stable@vger.kernel.org # 3.8
Tested-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Acked-by: Ian Munsie <imunsie@au1.ibm.com>
Tested-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Need to move the free function around a bit, but otherwise mostly
just removing code.
Specifically we can nuke all the _locked variants since the weak idr
reference is now protected by the idr_mutex, which we never hold
anywhere expect in the lookup/reg/unreg functions. And those never
call anything else.
Another benefit of this is that this patch switches the weak reference
logic from kref_put_mutex to kref_get_unless_zero. And the later is in
general more flexible wrt accomodating multiple weak references
protected by different locks, which might or might not come handy
eventually.
But one consequence of that switch is that we need to acquire the
blob_lock from the free function for the list_del calls. That's a bit
tricky to pull off, but works well if we pick the exact same scheme as
is already used for framebuffers. Most important changes:
- filp list is maintainer by create/destroy_blob ioctls directly
(already the case, so we can just remove the redundant list_del from
the free function).
- filp close handler walks the filp-private list lockless - works
because we know no one else can access it. I copied the same comment
from the fb code over to explain this.
- Otherwise we need to sufficiently restrict blob_lock critical
sections to avoid all the unreference calls. Easy to do once the
blob_lock only protects the list, and no longer the weak reference.
Cc: Dave Airlie <airlied@gmail.com>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie had at least the refcount leak fixed in a later patch (but
that patch does other things which need a bit more work). But we still
have the trouble that silly userspace could hit the WARN_ON in
drm_mode_object_find.
Fix this all up to make sure we don't leak objects, and don't spew
into demsg.
Fixes: d0f37cf629 ("drm/mode: move framebuffer reference into object.")
Testcase: igt/kms_addfb_basic/invalid-*-prop*
Cc: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Slipped through the cracks in my review. The one issue I spotted
is that drm_mode_object_find now acquires references and can be
used on FB objects, which caused follow-on bugs in get/set_prop ioctls.
Follow-up patches will fix that.
[airlied: fixup some incr fb/decr object mixups]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This is DRM driver for ARC PGU - simple bitstreamer used on
Synopsys ARC SDP boards (both AXS101 and AXS103).
* 'topic-arcpgu-v6' of https://github.com/foss-for-synopsys-dwc-arc-processors/linux:
arc: axs10x - add support of ARC PGU
MAINTAINERS: Add maintainer for ARC PGU display controller
drm: Add DT bindings documentation for ARC PGU display controller
drm: Add support of ARC PGU display controller
One cannot rename the struct at this point, so might as well remove the
comment.
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
virtio_gpu was failing to send vblank events when using the atomic IOCTL
with the DRM_MODE_PAGE_FLIP_EVENT flag set. This patch fixes each and
enables atomic pageflips updates.
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
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: Lyude <cpaul@redhat.com>
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Daniel 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: Dave Airlie <airlied@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: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Pull networking fixes from David Miller:
1) Handle v4/v6 mixed sockets properly in soreuseport, from Craig
Gallak.
2) Bug fixes for the new macsec facility (missing kmalloc NULL checks,
missing locking around netdev list traversal, etc.) from Sabrina
Dubroca.
3) Fix handling of host routes on ifdown in ipv6, from David Ahern.
4) Fix double-fdput in bpf verifier. From Jann Horn.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (31 commits)
bpf: fix double-fdput in replace_map_fd_with_map_ptr()
net: ipv6: Delete host routes on an ifdown
Revert "ipv6: Revert optional address flusing on ifdown."
net/mlx4_en: fix spurious timestamping callbacks
net: dummy: remove note about being Y by default
cxgbi: fix uninitialized flowi6
ipv6: Revert optional address flusing on ifdown.
ipv4/fib: don't warn when primary address is missing if in_dev is dead
net/mlx5: Add pci shutdown callback
net/mlx5_core: Remove static from local variable
net/mlx5e: Use vport MTU rather than physical port MTU
net/mlx5e: Fix minimum MTU
net/mlx5e: Device's mtu field is u16 and not int
net/mlx5_core: Add ConnectX-5 to list of supported devices
net/mlx5e: Fix MLX5E_100BASE_T define
net/mlx5_core: Fix soft lockup in steering error flow
qlcnic: Update version to 5.3.64
net: stmmac: socfpga: Remove re-registration of reset controller
macsec: fix netlink attribute validation
macsec: add missing macsec prefix in uapi
...
just a single fix to not move the GPU linear window on cores where it
might lead to inconsistent views of the memory by different engines in
the core, thus breaking relocs and possibly causing other fun.
* 'drm-etnaviv-fixes' of git://git.pengutronix.de:/git/lst/linux:
drm/etnaviv: don't move linear memory window on 3D cores without MC2.0
recent regressions. Changes are across several platforms, so
I'm listing every change separately here.
Regressions since 4.5:
- A correction of the psci firmware DT binding, to prevent
users from relying on unintended semantics
- Actually getting the newly merged clock driver for some OMAP
platforms to work
- A revert of patches for the Qualcomm BAM, these need to be
reworked for 4.7 to avoid breaking boards other than the one
they were intended for
- A correction for the I2C device nodes on the Socionext Uniphier
platform
- i.MX SDHCI was broken for non-DT platforms due to a change
with the setting of the DMA mask
- A revert of a patch that accidentally added a nonexisting
clock on the Rensas "Porter" board
- A couple of OMAP fixes that are all related to suspend after
the power domain changes for dra7
- On Mediatek, revert part of the power domain initialization
changes that broke mt8173-evb
Fixes for older bugs:
- Workaround for an "external abort" in the omap34xx
suspend/resume code.
- The USB1/eSATA should not be listed as an excon device on
am57xx-beagle-x15 (broken since v4.0)
- A v4.5 regression in the TI AM33xx and AM43XX DT specifying
incorrect DMA request lines for the GPMC
- The jiffies calibration on Renesas platforms was incorrect
for some modern CPU cores.
- A hardware errata woraround for clockdomains on TI DRA7
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAVx+5v2CrR//JCVInAQJ/ZBAArI3ZiR+Jj2dZCm9c7+PjlDWngJpBME3V
o4aF9CeyuA/eyx+QtKAq1ScG2eRIbfab03XGBMEHXpKmmiTXYFIcLFHewwSGBYsy
XUsNO+ZKsw92ImSdcX9p45BjkAADJvUwX5BzDlfOQ5mNX+o0Godb/8Mi2Y6RIqTK
5C0xQ0YE8ZN7xtyNzFylaI+CL6wsVLy6PUKig7UIrOOXQK3Tzt4mEz2ksrSBJzON
RiG7kPLf+Zd013WyF/ZUdC3VErDOP7C1Z+YRcK+2rxjlL+4oJUznsoaBYJgLUV+T
GmcD0TZNwt6x6FWF6cSiUa+gl+6oWRZwTGfUooS1zEcuLHBsONdMtVat4Z01RYos
rdMvFgZ6bxG7n4tajI2jg1gokGfyMfYuKwnHuA8Ynzn4N/VcnnbfxPRyV/RMLN0W
ad/e12SlLMX1XahrD9uo/oH/X73gHPnbHlLLzWfDfnyvNGvWiW3SNklFT03q/Yn+
fgfB0OnzG8+a3c/LHZbtAo/yYYLdqIuOg8I40AizN3CKHamUWPAjgFfdHdQADVV8
yC5ugVB6x7RYID/49IPT1C3n/SjoypYyRbo30ipqyz2dTf6kz35SY/YjYNSaIYvY
QfnGFuywsKsTprGAzI+x/fGo61Ve0/XkK9RPt0opU1+WdYr3sE+ufGVLVn4g4Cw3
wfd20UTVwGs=
=YgL2
-----END PGP SIGNATURE-----
Merge tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"Here are the latest bug fixes for ARM SoCs, mostly addressing recent
regressions. Changes are across several platforms, so I'm listing
every change separately here.
Regressions since 4.5:
- A correction of the psci firmware DT binding, to prevent users from
relying on unintended semantics
- Actually getting the newly merged clock driver for some OMAP
platforms to work
- A revert of patches for the Qualcomm BAM, these need to be reworked
for 4.7 to avoid breaking boards other than the one they were
intended for
- A correction for the I2C device nodes on the Socionext Uniphier
platform
- i.MX SDHCI was broken for non-DT platforms due to a change with the
setting of the DMA mask
- A revert of a patch that accidentally added a nonexisting clock on
the Rensas "Porter" board
- A couple of OMAP fixes that are all related to suspend after the
power domain changes for dra7
- On Mediatek, revert part of the power domain initialization changes
that broke mt8173-evb
Fixes for older bugs:
- Workaround for an "external abort" in the omap34xx suspend/resume
code.
- The USB1/eSATA should not be listed as an excon device on
am57xx-beagle-x15 (broken since v4.0)
- A v4.5 regression in the TI AM33xx and AM43XX DT specifying
incorrect DMA request lines for the GPMC
- The jiffies calibration on Renesas platforms was incorrect for some
modern CPU cores.
- A hardware errata woraround for clockdomains on TI DRA7"
* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
drivers: firmware: psci: unify enable-method binding on ARM {64,32}-bit systems
arm64: dts: uniphier: fix I2C nodes of PH1-LD20
ARM: shmobile: timer: Fix preset_lpj leading to too short delays
Revert "ARM: dts: porter: Enable SCIF_CLK frequency and pins"
ARM: dts: r8a7791: Don't disable referenced optional clocks
Revert "ARM: OMAP: Catch callers of revision information prior to it being populated"
ARM: OMAP3: Fix external abort on 36xx waking from off mode idle
ARM: dts: am57xx-beagle-x15: remove extcon_usb1
ARM: dts: am437x: Fix GPMC dma properties
ARM: dts: am33xx: Fix GPMC dma properties
Revert "soc: mediatek: SCPSYS: Fix double enabling of regulators"
ARM: mach-imx: sdhci-esdhc-imx: initialize DMA mask
ARM: DRA7: clockdomain: Implement timer workaround for errata i874
ARM: OMAP: Catch callers of revision information prior to it being populated
ARM: dts: dra7: Correct clock tree for sys_32k_ck
ARM: OMAP: DRA7: Provide proper class to omap2_set_globals_tap
ARM: OMAP: DRA7: wakeupgen: Skip SAR save for wakeupgen
Revert "dts: msm8974: Add dma channels for blsp2_i2c1 node"
Revert "dts: msm8974: Add blsp2_bam dma node"
ARM: dts: Add clocks for dm814x ADPLL
This is more prep-work for the upcoming pty changes. Still just code
cleanup with no actual semantic changes.
This removes a bunch pointless complexity by just having the slave pty
side remember the dentry associated with the devpts slave rather than
the inode. That allows us to remove all the "look up the dentry" code
for when we want to remove it again.
Together with moving the tty pointer from "inode->i_private" to
"dentry->d_fsdata" and getting rid of pointless inode locking, this
removes about 30 lines of code. Not only is the end result smaller,
it's simpler and easier to understand.
The old code, for example, depended on the d_find_alias() to not just
find the dentry, but also to check that it is still hashed, which in
turn validated the tty pointer in the inode.
That is a _very_ roundabout way to say "invalidate the cached tty
pointer when the dentry is removed".
The new code just does
dentry->d_fsdata = NULL;
in devpts_pty_kill() instead, invalidating the tty pointer rather more
directly and obviously. Don't do something complex and subtle when the
obvious straightforward approach will do.
The rest of the patch (ie apart from code deletion and the above tty
pointer clearing) is just switching the calling convention to pass the
dentry or file pointer around instead of the inode.
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Peter Hurley <peter@hurleysoftware.com>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>
Cc: Willy Tarreau <w@1wt.eu>
Cc: Aurelien Jarno <aurelien@aurel32.net>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: Jann Horn <jann@thejh.net>
Cc: Greg KH <greg@kroah.com>
Cc: Jiri Slaby <jslaby@suse.com>
Cc: Florian Weimer <fw@deneb.enyo.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* ak8975
- fix a null pointer exception if an interrupt occurs during probe.
- fix a maybe-unitialized warning.
* at91-sama5d2
- fix a crash on removal of the module.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJXHmHrAAoJEFSFNJnE9BaI8nAQALJLXFmHy1pF51F+lHoOnUf0
Uezdtydg8dzRoLFn85Ky3IxUGGBnEf6UHMAbIplisNCEodOCs6LITJNqU9kUrJdB
mWR/6JQPSzH6CpOK0qpGrZ8wTiDT/8YwbD+4TEUkmPf+eZ/jZblmoxpWcl3z2FsW
4ju9w9xtq+Fj0msPmhrb19goAFG0lc6R4B01XnbO16zzGO13Ps98LvRSOXUfH0j8
+OUWSC/teOVa7Fs+iBbB2vLuoZH2jLZJE/xKCOCh3A/SqXYB3SqrkVPZFIqYWGOp
Sdq3ErcWG3qsMMojbeBLWD+lNro/mxTKp0uEsGFZnyj7N0xizsrnBsW8KwDAEgxf
fHYZ1RuXVokQbJEebb1H2ArkGAPjPtpVZknbsR20oWXFplLNEOZ0ugN9Atd3JR7t
4pY0ZUxyLqcGyQLDx1RKgkp8dA3pXCZd2kQI2fDxcuDOC38mmx21A+Wk5Ef+xuyP
MOcIHcOFBV+YEwnVi7wDq04jfgnqs3SLAQdWhIS0JWvwSi/aJBCnhmsQ5kQ5lpkD
e8HjYja8fzyIJPXeF7ixbrlkpws4C+3wdm+C10yjuIrQ7TsHmpcdX27oWGDNHUB2
xDHUmQYa5D3dlOhdn71RK4RNVKrNcvF30NEDiCT5strA+bagxApNgZxk9vizxPMi
zHfqDynVk/2dGDcedNo7
=VS4P
-----END PGP SIGNATURE-----
Merge tag 'iio-fixes-for-4.6c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
3rd set of IIO fixes for the 4.6 cycle.
* ak8975
- fix a null pointer exception if an interrupt occurs during probe.
- fix a maybe-unitialized warning.
* at91-sama5d2
- fix a crash on removal of the module.
The usb_get_phy() function returns either a valid pointer to phy or
ERR_PTR() error, check for NULL always fails and may lead to oops on
error path, fix this issue.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This reverts commit 2035772010.
Commit 20357720 claims throughput improvement for MSC/UVC, but I
don't see much improvement. Following are the MSC measurement using
dd on AM335x GP EVM.
with BCD_BH: read: 14.9MB/s, write: 20.9MB/s
without BCD_BH: read: 15.2MB/s, write: 21.2MB/s
However with this commit the following regressions have been observed.
1. ASIX usb-ethernet dongle is completely broken on UDP RX.
2. Unpluging a 3G modem, which uses option driver, behind a hub causes
console log flooding with the following message.
option_instat_callback: error -71
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Some functions, such as f_sourcesink, rely on an endpoint's desc
field during their requests' complete() callback, so clear it only
_after_ nuking all requests to avoid NULL pointer dereference.
Signed-off-by: Tal Shorer <tal.shorer@gmail.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When bpf(BPF_PROG_LOAD, ...) was invoked with a BPF program whose bytecode
references a non-map file descriptor as a map file descriptor, the error
handling code called fdput() twice instead of once (in __bpf_map_get() and
in replace_map_fd_with_map_ptr()). If the file descriptor table of the
current task is shared, this causes f_count to be decremented too much,
allowing the struct file to be freed while it is still in use
(use-after-free). This can be exploited to gain root privileges by an
unprivileged user.
This bug was introduced in
commit 0246e64d9a ("bpf: handle pseudo BPF_LD_IMM64 insn"), but is only
exploitable since
commit 1be7f75d16 ("bpf: enable non-root eBPF programs") because
previously, CAP_SYS_ADMIN was required to reach the vulnerable code.
(posted publicly according to request by maintainer)
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 320d25b6a0.
This change was problematic for a couple of reasons:
1. It missed a some entry points (Xen things and 64-bit native).
2. The entry it changed can be executed more than once. This isn't
really a problem, but it conflated per-cpu state setup and global
state setup.
3. It broke 64-bit non-NX. 64-bit non-NX worked the other way around from
32-bit -- __supported_pte_mask had NX set initially and was *cleared*
in x86_configure_nx. With the patch applied, it never got cleared.
Reported-and-tested-by: Meelis Roos <mroos@linux.ee>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/59bd15f7f4b56b633a611b7f70876c6d2ad01a98.1461685884.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Without that, regulators are left in the mode last set by the bootloader or
by the kernel the device was rebooted from. This leads to various problems,
like non-working peripherals.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
Reviewed-by: Javier Martinez Canillas <javier@osg.samsung.com>
Reviewed-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Tony Lindgren <tony@atomide.com>
According to the TRM, SCM CONTROL_CSIRXFE register is on offset 0x6c
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Reviewed-By: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ldo4_reg is connected to DSS, and should always be 1.8V. However the The
dts defines a range of 1.5V-1.8V, which requires somethings to set the
actual voltage at runtime. Currently we set the voltage in omapdss
driver.
As the voltage must always be 1.8V, let's just define the range to 1.8V
so that the driver doesn't need to deal with the voltage. In fact, the
driver should not touch the voltage, except in the cases where the
voltage needs to be changed at runtime.
I presume the situation is the same for ldo1_reg, used for CSI, although
I think it is not currently used in the mainline.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ldo4_reg is connected to DSS, and should always be 1.8V. However the
The dts defines a range of 1.5V-1.8V, which requires somethings to set
the actual voltage at runtime. Currently we set the voltage in omapdss
driver.
As the voltage must always be 1.8V, let's just define the range to 1.8V
so that the driver doesn't need to deal with the voltage. In fact, the
driver should not touch the voltage, except in the cases where the
voltage needs to be changed at runtime.
I presume the situation is the same for ldo1_reg, used for CSI, although
I think it is not currently used in the mainline.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
In c4iw_drain_sq/rq(), if the particular queue is already empty
then don't block.
Fixes: ce4af14d94aa ('iw_cxgb4: add queue drain functions')
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
The IWCM uses ibdev.iwcm->ifname for registration with the iwarp
port map daemon. But iw_cxgb3 did not initialize this field which
causes intermittent registration failures based on the contents of the
uninitialized memory.
Fixes: c1340e8aa6 ("iw_cxgb3: support for iWARP port mapping")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
The IWCM uses ibdev.iwcm->ifname for registration with the iwarp
port map daemon. But iw_cxgb4 did not initialize this field which
causes intermittent registration failures based on the contents of the
uninitialized memory.
Fixes: 170003c894 ("iw_cxgb4: remove port mapper related code")
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
The drain_rq function expects a normal receive qp to drain. A qp can
only have either a normal rq or an srq. If there is an srq, there
is no rq to drain. Until the API supports draining SRQs, simply
skip draining the rq when the qp has an srq attached.
Fixes: 765d67748b ("IB: new common API for draining queues")
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Doug Ledford <dledford@redhat.com>
It was a simple idea -- save IPv6 configured addresses on a link down
so that IPv6 behaves similar to IPv4. As always the devil is in the
details and the IPv6 stack as too many behavioral differences from IPv4
making the simple idea more complicated than it needs to be.
The current implementation for keeping IPv6 addresses can panic or spit
out a warning in one of many paths:
1. IPv6 route gets an IPv4 route as its 'next' which causes a panic in
rt6_fill_node while handling a route dump request.
2. rt->dst.obsolete is set to DST_OBSOLETE_DEAD hitting the WARN_ON in
fib6_del
3. Panic in fib6_purge_rt because rt6i_ref count is not 1.
The root cause of all these is references related to the host route for
an address that is retained.
So, this patch deletes the host route every time the ifdown loop runs.
Since the host route is deleted and will be re-generated an up there is
no longer a need for the l3mdev fix up. On the 'admin up' side move
addrconf_permanent_addr into the NETDEV_UP event handling so that it
runs only once versus on UP and CHANGE events.
All of the current panics and warnings appear to be related to
addresses on the loopback device, but given the catastrophic nature when
a bug is triggered this patch takes the conservative approach and evicts
all host routes rather than trying to determine when it can be re-used
and when it can not. That can be a later optimizaton if desired.
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
This reverts commit 841645b5f2.
Ok, this puts the feature back. I've decided to apply David A.'s
bug fix and run with that rather than make everyone wait another
whole release for this feature.
Signed-off-by: David S. Miller <davem@davemloft.net>
This updates MAINTEINERS file with information about maintainer of
ARC PGU display controller driver.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
The bug in a workqueue leads to a stalled IO request in MQ ctx->rq_list
with the following backtrace:
[ 601.347452] INFO: task kworker/u129:5:1636 blocked for more than 120 seconds.
[ 601.347574] Tainted: G O 4.4.5-1-storage+ #6
[ 601.347651] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 601.348142] kworker/u129:5 D ffff880803077988 0 1636 2 0x00000000
[ 601.348519] Workqueue: ibnbd_server_fileio_wq ibnbd_dev_file_submit_io_worker [ibnbd_server]
[ 601.348999] ffff880803077988 ffff88080466b900 ffff8808033f9c80 ffff880803078000
[ 601.349662] ffff880807c95000 7fffffffffffffff ffffffff815b0920 ffff880803077ad0
[ 601.350333] ffff8808030779a0 ffffffff815b01d5 0000000000000000 ffff880803077a38
[ 601.350965] Call Trace:
[ 601.351203] [<ffffffff815b0920>] ? bit_wait+0x60/0x60
[ 601.351444] [<ffffffff815b01d5>] schedule+0x35/0x80
[ 601.351709] [<ffffffff815b2dd2>] schedule_timeout+0x192/0x230
[ 601.351958] [<ffffffff812d43f7>] ? blk_flush_plug_list+0xc7/0x220
[ 601.352208] [<ffffffff810bd737>] ? ktime_get+0x37/0xa0
[ 601.352446] [<ffffffff815b0920>] ? bit_wait+0x60/0x60
[ 601.352688] [<ffffffff815af784>] io_schedule_timeout+0xa4/0x110
[ 601.352951] [<ffffffff815b3a4e>] ? _raw_spin_unlock_irqrestore+0xe/0x10
[ 601.353196] [<ffffffff815b093b>] bit_wait_io+0x1b/0x70
[ 601.353440] [<ffffffff815b056d>] __wait_on_bit+0x5d/0x90
[ 601.353689] [<ffffffff81127bd0>] wait_on_page_bit+0xc0/0xd0
[ 601.353958] [<ffffffff81096db0>] ? autoremove_wake_function+0x40/0x40
[ 601.354200] [<ffffffff81127cc4>] __filemap_fdatawait_range+0xe4/0x140
[ 601.354441] [<ffffffff81127d34>] filemap_fdatawait_range+0x14/0x30
[ 601.354688] [<ffffffff81129a9f>] filemap_write_and_wait_range+0x3f/0x70
[ 601.354932] [<ffffffff811ced3b>] blkdev_fsync+0x1b/0x50
[ 601.355193] [<ffffffff811c82d9>] vfs_fsync_range+0x49/0xa0
[ 601.355432] [<ffffffff811cf45a>] blkdev_write_iter+0xca/0x100
[ 601.355679] [<ffffffff81197b1a>] __vfs_write+0xaa/0xe0
[ 601.355925] [<ffffffff81198379>] vfs_write+0xa9/0x1a0
[ 601.356164] [<ffffffff811c59d8>] kernel_write+0x38/0x50
The underlying device is a null_blk, with default parameters:
queue_mode = MQ
submit_queues = 1
Verification that nullb0 has something inflight:
root@pserver8:~# cat /sys/block/nullb0/inflight
0 1
root@pserver8:~# find /sys/block/nullb0/mq/0/cpu* -name rq_list -print -exec cat {} \;
...
/sys/block/nullb0/mq/0/cpu2/rq_list
CTX pending:
ffff8838038e2400
...
During debug it became clear that stalled request is always inserted in
the rq_list from the following path:
save_stack_trace_tsk + 34
blk_mq_insert_requests + 231
blk_mq_flush_plug_list + 281
blk_flush_plug_list + 199
wait_on_page_bit + 192
__filemap_fdatawait_range + 228
filemap_fdatawait_range + 20
filemap_write_and_wait_range + 63
blkdev_fsync + 27
vfs_fsync_range + 73
blkdev_write_iter + 202
__vfs_write + 170
vfs_write + 169
kernel_write + 56
So blk_flush_plug_list() was called with from_schedule == true.
If from_schedule is true, that means that finally blk_mq_insert_requests()
offloads execution of __blk_mq_run_hw_queue() and uses kblockd workqueue,
i.e. it calls kblockd_schedule_delayed_work_on().
That means, that we race with another CPU, which is about to execute
__blk_mq_run_hw_queue() work.
Further debugging shows the following traces from different CPUs:
CPU#0 CPU#1
---------------------------------- -------------------------------
reqeust A inserted
STORE hctx->ctx_map[0] bit marked
kblockd_schedule...() returns 1
<schedule to kblockd workqueue>
request B inserted
STORE hctx->ctx_map[1] bit marked
kblockd_schedule...() returns 0
*** WORK PENDING bit is cleared ***
flush_busy_ctxs() is executed, but
bit 1, set by CPU#1, is not observed
As a result request B pended forever.
This behaviour can be explained by speculative LOAD of hctx->ctx_map on
CPU#0, which is reordered with clear of PENDING bit and executed _before_
actual STORE of bit 1 on CPU#1.
The proper fix is an explicit full barrier <mfence>, which guarantees
that clear of PENDING bit is to be executed before all possible
speculative LOADS or STORES inside actual work function.
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Cc: Gioh Kim <gi-oh.kim@profitbricks.com>
Cc: Michael Wang <yun.wang@profitbricks.com>
Cc: Tejun Heo <tj@kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: linux-block@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: stable@vger.kernel.org
Signed-off-by: Tejun Heo <tj@kernel.org>
ARC PGU could be found on some development boards from Synopsys.
This is a simple byte streamer that reads data from a framebuffer
and sends data to the single encoder.
Signed-off-by: Carlos Palminha <palminha@synopsys.com>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-snps-arc@lists.infradead.org
Currently ARM CPUs DT bindings allows different enable-method value for
PSCI based systems. On ARM 64-bit this property is required and must be
"psci" while on ARM 32-bit systems this property is optional and must
be "arm,psci" if present.
However, "arm,psci" has always been the compatible string for the PSCI
node, and was never intended to be the enable-method. So this is a bug
in the binding and not a deliberate attempt at specifying 32-bit
differently.
This is problematic if 32-bit OS is run on 64-bit system which has
"psci" as enable-method rather than the expected "arm,psci".
So let's unify the value into "psci" and remove support for "arm,psci"
before it finds any users.
Reported-by: Soby Mathew <Soby.Mathew@arm.com>
Cc: Rob Herring <robh+dt@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The recent bug report suggests that BCLK setup for i915 HSW/BDW needs
to be updated at each HDMI hotplug, not only at initialization and
resume. That is, we need to update HSW_EM4 and HSW_EM5 registers at
ELD notification, too. Otherwise the HDMI audio may be out of sync
and played in a wrong pitch.
However, the HDA codec driver has no access to the controller
registers, and currently the code managing these registers is in
hda_intel.c, i.e. local to the controller driver. For allowing the
explicit BCLK update from the codec driver, as in this patch, the
former haswell_set_bclk() in hda_intel.c is moved to hdac_i915.c and
exposed as snd_hdac_i915_set_bclk(). This is called from both the HDA
controller driver and intel_pin_eld_notify() in HDMI codec driver.
Along with this change, snd_hdac_get_display_clk() gets dropped as
it's no longer used.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91410
Cc: <stable@vger.kernel.org> # v4.5+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Fixes audio output on a ThinkPad X260, when using Lenovo CES 2013
docking station series (basic, pro, ultra).
Signed-off-by: Conrad Kostecki <ck+linuxkernel@bl4ckb0x.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The driver supports now a second platform and received several
fixes, hence a version increment is justified.
Signed-off-by: Stefan Agner <stefan@agner.ch>
When multiple skb are TX-completed in a row, we might incorrectly keep
a timestamp of a prior skb and cause extra work.
Fixes: ec693d4701 ("net/mlx4_en: Add HW timestamping (TS) support")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Willem de Bruijn <willemb@google.com>
Reviewed-by: Eran Ben Elisha <eranbe@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
