- 19 Jun, 2019 13 commits
-
-
Takashi Sakamoto authored
commit d8fa87c3 upstream. Stanton SCS.1m can transfer isochronous packet with Multi Bit Linear Audio data channels, therefore it allows software to capture PCM substream. However, ALSA oxfw driver doesn't. This commit changes the driver to add one PCM substream for capture direction. Fixes: de5126cc ("ALSA: oxfw: add stream format quirk for SCS.1 models") Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Hui Wang authored
commit 17d30460 upstream. This reverts commit 9cb40eb1. This patch introduces noise and headphone playback issue after rebooting or suspending/resuming. Let us revert it. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203831 Fixes: 9cb40eb1 ("ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops") Cc: <stable@vger.kernel.org> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
-
Jason Gerecke authored
commit 69dbdfff upstream. The Bluetooth interface of the 2nd-gen Intuos Pro batches together four independent "frames" of finger data into a single report. Each frame is essentially equivalent to a single USB report, with the up-to-10 fingers worth of information being spread across two frames. At the moment the driver only calls `input_sync` after processing all four frames have been processed, which can result in the driver sending multiple updates for a single slot within the same SYN_REPORT. This can confuse userspace, so modify the driver to sync more often if necessary (i.e., after reporting the state of all fingers). Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
Jason Gerecke <jason.gerecke@wacom.com> Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Jason Gerecke authored
commit 6441fc78 upstream. The button numbering of the 2nd-gen Intuos Pro is not consistent between the USB and Bluetooth interfaces. Over USB, the HID_GENERIC codepath enumerates the eight ExpressKeys first (BTN_0 - BTN_7) followed by the center modeswitch button (BTN_8). The Bluetooth codepath, however, has the center modeswitch button as BTN_0 and the the eight ExpressKeys as BTN_1 - BTN_8. To ensure userspace button mappings do not change depending on how the tablet is connected, modify the Bluetooth codepath to report buttons in the same order as USB. To ensure the mode switch LED continues to toggle in response to the mode switch button, the `wacom_is_led_toggled` function also requires a small update. Link: https://github.com/linuxwacom/input-wacom/pull/79 Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
Aaron Skomra <aaron.skomra@wacom.com> Signed-off-by:
-
Jason Gerecke authored
commit fe7f8d73 upstream. The Bluetooth reports from the 2nd-gen Intuos Pro have separate bits for indicating if the tip or eraser is in contact with the tablet. At the moment, only the tip contact bit controls the state of the BTN_TOUCH event. This prevents the eraser from working as expected. This commit changes the driver to send BTN_TOUCH whenever either the tip or eraser contact bit is set. Fixes: 4922cd26 ("HID: wacom: Support 2nd-gen Intuos Pro's Bluetooth classic interface") Cc: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
-
Jason Gerecke authored
commit e92a7be7 upstream. If the tool spends some time in prox before entering range, a series of events (e.g. ABS_DISTANCE, MSC_SERIAL) can be sent before we or userspace have any clue about the pen whose data is being reported. We need to hold off on reporting anything until the pen has entered range. Since we still want to report events that occur "in prox" after the pen has *left* range we use 'wacom-tool[0]' as the indicator that the pen did at one point enter range and provide us/userspace with tool type and serial number information. Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range") Cc: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
-
Jason Gerecke authored
commit 2cc08800 upstream. The serial number and tool type information that is reported by the tablet while a pen is merely "in prox" instead of fully "in range" can be stale and cause us to report incorrect tool information. Serial number, tool type, and other information is only valid once the pen comes fully in range so we should be careful to not use this information until that point. In particular, this issue may cause the driver to incorectly report BTN_TOOL_RUBBER after switching from the eraser tool back to the pen. Fixes: a48324de ("HID: wacom: Bluetooth IRQ for Intuos Pro should handle prox/range") Cc: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
-
Benjamin Tissoires authored
commit 81bcbad5 upstream. Since kernel v5.0, one single win8 touchscreen device failed. And it turns out this is because it reports 2 InRange usage per touch. It's a first, and I *really* wonder how this was allowed by Microsoft in the first place. But IIRC, Breno told me this happened *after* a firmware upgrade... Anyway, better be safe for those crappy devices, and make sure we have a full slot before jumping to the next. This won't prevent all crappy devices to fail here, but at least we will have a safeguard as long as the contact ID and the X and Y coordinates are placed in the report after the grabage. Fixes: 01eaac7e ("HID: multitouch: remove one copy of values") CC: stable@vger.kernel.org # v5.0+ Reported-and-tested-by:
Breno Leitao <leitao@debian.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Benjamin Tissoires authored
commit 15fc1b5c upstream. This reverts commit 94a9992f. The commit allows for more than 32 bits in hid_field_extract(), but the return value is a 32 bits int. So basically what this commit is doing is just silencing those legitimate errors. Revert to a previous situation in the hope that a proper fix will be impletemented. Fixes: 94a9992f ("HID: Increase maximum report size allowed by hid_field_extract()") Cc: stable@vger.kernel.org # v5.1 Acked-by:
-
Benjamin Tissoires authored
commit 39b3c3a5 upstream. The value field is actually an array of .maxfield. We should assign the correct number to the correct usage. Not that we never encounter a device that requires this ATM, but better have the proper code path. Fixes: 2dc702c9 ("HID: input: use the Resolution Multiplier for high-resolution scrolling") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by:
-
Benjamin Tissoires authored
commit d43c17ea upstream. Some old mice have a tendency to not accept the high resolution multiplier. They reply with a -EPIPE which was previously ignored. Force the call to resolution multiplier to be synchronous and actually check for the answer. If this fails, consider the mouse like a normal one. Fixes: 2dc702c9 ("HID: input: use the Resolution Multiplier for high-resolution scrolling") Link: https://bugzilla.redhat.com/show_bug.cgi?id=1700071Reported-and-tested-by:
James Feeney <james@nurealm.net> Cc: stable@vger.kernel.org # v5.0+ Signed-off-by:
-
Thomas Backlund authored
Not-entirely-upstream-sha1-but-equivalent: bed2dd84 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Setting CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n (added by commit: b30a43ac) causes the build to fail with: ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! This does not happend upstream as the offending code got removed in: bed2dd84 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") Fix that by adding check for CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT around the drm_legacy_mmap() call. Also, as Sven Joachim pointed out, we need to make the check in CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n case return -EINVAL as its done for basically all other gpu drivers, especially in upstream kernels drivers/gpu/drm/ttm/ttm_bo_vm.c as of the upstream commit bed2dd84. NOTE. This is a minimal stable-only fix for trees where b30a43ac is backported as the build error affects nouveau only. Fixes: b30a43ac ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") Signed-off-by:
Thomas Backlund <tmb@mageia.org> Cc: stable@vger.kernel.org Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Sven Joachim <svenjoac@gmx.de> Signed-off-by:
-
Dave Airlie authored
commit b30a43ac upstream. There was a nouveau DDX that relied on legacy context ioctls to work, but we fixed it years ago, give distros that have a modern DDX the option to break the uAPI and close the mess of holes that legacy context support is. Full context of the story: commit 0e975980 Author: Peter Antoine <peter.antoine@intel.com> Date: Tue Jun 23 08:18:49 2015 +0100 drm: Turn off Legacy Context Functions The context functions are not used by the i915 driver and should not be used by modeset drivers. These driver functions contain several bugs and security holes. This change makes these functions optional can be turned on by a setting, they are turned off by default for modeset driver with the exception of the nouvea driver that may require them with an old version of libdrm. The previous attempt was commit 7c510133 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Aug 8 15:41:21 2013 +0200 drm: mark context support as a legacy subsystem but this had to be reverted commit c21eb21c Author: Dave Airlie <airlied@redhat.com> Date: Fri Sep 20 08:32:59 2013 +1000 Revert "drm: mark context support as a legacy subsystem" v2: remove returns from void function, and formatting (Daniel Vetter) v3: - s/Nova/nouveau/ in the commit message, and add references to the previous attempts - drop the part touching the drm hw lock, that should be a separate patch. Signed-off-by: Peter Antoine <peter.antoine@intel.com> (v2) Cc: Peter Antoine <peter.antoine@intel.com> (v2) Reviewed-by:
Peter Antoine <peter.antoine@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> v2: move DRM_VM dependency into legacy config. v3: fix missing dep (kbuild robot) Cc: stable@vger.kernel.org Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
- 17 Jun, 2019 5 commits
-
-
Greg Kroah-Hartman authored
-
Eric Dumazet authored
commit 967c05ae upstream. If mtu probing is enabled tcp_mtu_probing() could very well end up with a too small MSS. Use the new sysctl tcp_min_snd_mss to make sure MSS search is performed in an acceptable range. CVE-2019-11479 -- tcp mss hardcoded to 48 Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Cc: Jonathan Looney <jtl@netflix.com> Acked-by:
Neal Cardwell <ncardwell@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Eric Dumazet authored
commit 5f3e2bf0 upstream. Some TCP peers announce a very small MSS option in their SYN and/or SYN/ACK messages. This forces the stack to send packets with a very high network/cpu overhead. Linux has enforced a minimal value of 48. Since this value includes the size of TCP options, and that the options can consume up to 40 bytes, this means that each segment can include only 8 bytes of payload. In some cases, it can be useful to increase the minimal value to a saner value. We still let the default to 48 (TCP_MIN_SND_MSS), for compatibility reasons. Note that TCP_MAXSEG socket option enforces a minimal value of (TCP_MIN_MSS). David Miller increased this minimal value in commit c39508d6 ("tcp: Make TCP_MAXSEG minimum more correct.") from 64 to 88. We might in the future merge TCP_MIN_SND_MSS and TCP_MIN_MSS. CVE-2019-11479 -- tcp mss hardcoded to 48 Signed-off-by:
Jonathan Looney <jtl@netflix.com> Acked-by:
-
Eric Dumazet authored
commit f070ef2a upstream. Jonathan Looney reported that a malicious peer can force a sender to fragment its retransmit queue into tiny skbs, inflating memory usage and/or overflow 32bit counters. TCP allows an application to queue up to sk_sndbuf bytes, so we need to give some allowance for non malicious splitting of retransmit queue. A new SNMP counter is added to monitor how many times TCP did not allow to split an skb if the allowance was exceeded. Note that this counter might increase in the case applications use SO_SNDBUF socket option to lower sk_sndbuf. CVE-2019-11478 : tcp_fragment, prevent fragmenting a packet when the socket is already using more than half the allowed space Signed-off-by:
Yuchung Cheng <ycheng@google.com> Reviewed-by:
Tyler Hicks <tyhicks@canonical.com> Cc: Bruce Curtis <brucec@netflix.com> Cc: Jonathan Lemon <jonathan.lemon@gmail.com> Signed-off-by:
-
Eric Dumazet authored
commit 3b4929f6 upstream. Jonathan Looney reported that TCP can trigger the following crash in tcp_shifted_skb() : BUG_ON(tcp_skb_pcount(skb) < pcount); This can happen if the remote peer has advertized the smallest MSS that linux TCP accepts : 48 An skb can hold 17 fragments, and each fragment can hold 32KB on x86, or 64KB on PowerPC. This means that the 16bit witdh of TCP_SKB_CB(skb)->tcp_gso_segs can overflow. Note that tcp_sendmsg() builds skbs with less than 64KB of payload, so this problem needs SACK to be enabled. SACK blocks allow TCP to coalesce multiple skbs in the retransmit queue, thus filling the 17 fragments to maximal capacity. CVE-2019-11477 -- u16 overflow of TCP_SKB_CB(skb)->tcp_gso_segs Fixes: 832d11c5 ("tcp: Try to restore large SKBs while SACK processing") Signed-off-by:
-
- 15 Jun, 2019 22 commits
-
-
Greg Kroah-Hartman authored
-
Jens Axboe authored
commit 44a9bd18 upstream. The test case we have is rightfully failing with the current kernel: io_uring_setup(1, 0x7ffe2cafebe0), flags: IORING_SETUP_SQPOLL|IORING_SETUP_SQ_AFF, resv: 0x00000000 0x00000000 0x00000000 0x00000000 0x00000000, sq_thread_cpu: 4 expected -1, got 3 This is in a vm, and CPU3 is the last valid one, hence asking for 4 should fail the setup with -EINVAL, not succeed. The problem is that we're using array_index_nospec() with nr_cpu_ids as the index, hence we wrap and end up using CPU0 instead of CPU4. This makes the setup succeed where it should be failing. We don't need to use array_index_nospec() as we're not indexing any array with this. Instead just compare with nr_cpu_ids directly. This is fine as we're checking with cpu_online() afterwards. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Takashi Iwai authored
commit 7c32ae35 upstream. The call of unsubscribe_port() which manages the group count and module refcount from delete_and_unsubscribe_port() looks racy; it's not covered by the group list lock, and it's likely a cause of the reported unbalance at port deletion. Let's move the call inside the group list_mutex to plug the hole. Reported-by: syzbot+e4c8abb920efa77bace9@syzkaller.appspotmail.com Signed-off-by:
-
Amir Goldstein authored
commit 9e46b840 upstream. Overlay file f_pos is the master copy that is preserved through copy up and modified on read/write, but only real fs knows how to SEEK_HOLE/SEEK_DATA and real fs may impose limitations that are more strict than ->s_maxbytes for specific files, so we use the real file to perform seeks. We do not call real fs for SEEK_CUR:0 query and for SEEK_SET:0 requests. Fixes: d1d04ef8 ("ovl: stack file ops") Reported-by:
Eddie Horng <eddiehorng.tw@gmail.com> Signed-off-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com> Signed-off-by:
-
Jiufei Xue authored
commit 98487de3 upstream. We found that it return success when we set IMMUTABLE_FL flag to a file in docker even though the docker didn't have the capability CAP_LINUX_IMMUTABLE. The commit d1d04ef8 ("ovl: stack file ops") and dab5ca8f ("ovl: add lsattr/chattr support") implemented chattr operations on a regular overlay file. ovl_real_ioctl() overridden the current process's subjective credentials with ofs->creator_cred which have the capability CAP_LINUX_IMMUTABLE so that it will return success in vfs_ioctl()->cap_capable(). Fix this by checking the capability before cred overridden. And here we only care about APPEND_FL and IMMUTABLE_FL, so get these information from inode. [SzM: move check and call to underlying fs inside inode locked region to prevent two such calls from racing with each other] Signed-off-by:
Jiufei Xue <jiufei.xue@linux.alibaba.com> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 1e07d637 which is commit b30a43ac upstream. Sven reports: Commit 1e07d637 ("drm/nouveau: add kconfig option to turn off nouveau legacy contexts. (v3)") has caused a build failure for me when I actually tried that option (CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT=n): ,---- | Kernel: arch/x86/boot/bzImage is ready (#1) | Building modules, stage 2. | MODPOST 290 modules | ERROR: "drm_legacy_mmap" [drivers/gpu/drm/nouveau/nouveau.ko] undefined! | scripts/Makefile.modpost:91: recipe for target '__modpost' failed `---- Upstream does not have that problem, as commit bed2dd84 ("drm/ttm: Quick-test mmap offset in ttm_bo_mmap()") has removed the use of drm_legacy_mmap from nouveau_ttm.c. Unfortunately that commit does not apply in 5.1.9. The ensuing discussion proposed a number of one-off patches, but no solid agreement was made, so just revert the commit for now to get people's systems building again. Reported-by:
Sven Joachim <svenjoac@gmx.de> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Dave Airlie <airlied@redhat.com> Cc: Thomas Backlund <tmb@mageia.org> Signed-off-by:
-
Greg Kroah-Hartman authored
This reverts commit 07e38998 which is commit d5bb334a upstream. Lots of people have reported issues with this patch, and as there does not seem to be a fix going into Linus's kernel tree any time soon, revert the commit in the stable trees so as to get people's machines working properly again. Reported-by:
Vasily Khoruzhick <anarsoul@gmail.com> Reported-by:
Hans de Goede <hdegoede@redhat.com> Cc: Jeremy Cline <jeremy@jcline.org> Cc: Marcel Holtmann <marcel@holtmann.org> Cc: Johan Hedberg <johan.hedberg@intel.com> Signed-off-by:
-
Dennis Zhou authored
[ Upstream commit 8c43004a ] pcpu_find_block_fit() guarantees that a fit is found within PCPU_BITMAP_BLOCK_BITS. Iteration is used to determine the first fit as it compares against the block's contig_hint. This can lead to incorrectly scanning past the end of the bitmap. The behavior was okay given the check after for bit_off >= end and the correctness of the hints from pcpu_find_block_fit(). This patch fixes this by bounding the end offset by the number of bits in a chunk. Signed-off-by:
Dennis Zhou <dennis@kernel.org> Reviewed-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Andrey Smirnov authored
[ Upstream commit 338aa107 ] Fix the warning produced by gpiochip_set_irq_hooks() by allocating a dedicated IRQ chip per GPIO chip/port. Signed-off-by:
Andrey Smirnov <andrew.smirnov@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Bartosz Golaszewski <bgolaszewski@baylibre.com> Cc: Chris Healy <cphealy@gmail.com> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Heiner Kallweit <hkallweit1@gmail.com> Cc: Fabio Estevam <festevam@gmail.com> Cc: linux-gpio@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: linux-imx@nxp.com Signed-off-by:
Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by:
-
Marek Vasut authored
[ Upstream commit d5aa8408 ] Porter needs the regulator quirk, just like the other boards. But unlike the other boards, the Porter uses DA9063L, which is at 0x5a. Otherwise, DA9063L and DA9210 IRQ line is still connected to CPU IRQ2 . Signed-off-by:
Marek Vasut <marek.vasut+renesas@gmail.com> Acked-by:
Wolfram Sang <wsa+renesas@sang-engineering.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
-
Takeshi Kihara authored
[ Upstream commit 15160f6d ] The Product Register of R-Car M3-W ES1.3 incorrectly identifies the SoC revision as ES2.1. Add a workaround to fix this. Signed-off-by:
Takeshi Kihara <takeshi.kihara.df@renesas.com> Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 32a155b1 ] The datasheet says the vconn MUST be off when we start toggling. The tcpm.c state-machine is responsible to make sure vconn is off, but lets add a WARN to catch any cases where vconn is not off for some reason. Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Reviewed-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Marek Szyprowski authored
[ Upstream commit 4d8e3e95 ] During early system resume on Exynos5422 with performance counters enabled the following kernel oops happens: Internal error: Oops - undefined instruction: 0 [#1] PREEMPT SMP ARM Modules linked in: CPU: 0 PID: 1433 Comm: bash Tainted: G W 5.0.0-rc5-next-20190208-00023-gd5fb5a8a13e6-dirty #5480 Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) ... Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4451006a DAC: 00000051 Process bash (pid: 1433, stack limit = 0xb7e0e22f) ... (reset_ctrl_regs) from [<c0112ad0>] (dbg_cpu_pm_notify+0x1c/0x24) (dbg_cpu_pm_notify) from [<c014c840>] (notifier_call_chain+0x44/0x84) (notifier_call_chain) from [<c014cbc0>] (__atomic_notifier_call_chain+0x7c/0x128) (__atomic_notifier_call_chain) from [<c01ffaac>] (cpu_pm_notify+0x30/0x54) (cpu_pm_notify) from [<c055116c>] (syscore_resume+0x98/0x3f4) (syscore_resume) from [<c0189350>] (suspend_devices_and_enter+0x97c/0xe74) (suspend_devices_and_enter) from [<c0189fb8>] (pm_suspend+0x770/0xc04) (pm_suspend) from [<c0187740>] (state_store+0x6c/0xcc) (state_store) from [<c09fa698>] (kobj_attr_store+0x14/0x20) (kobj_attr_store) from [<c030159c>] (sysfs_kf_write+0x4c/0x50) (sysfs_kf_write) from [<c0300620>] (kernfs_fop_write+0xfc/0x1e0) (kernfs_fop_write) from [<c0282be8>] (__vfs_write+0x2c/0x160) (__vfs_write) from [<c0282ea4>] (vfs_write+0xa4/0x16c) (vfs_write) from [<c0283080>] (ksys_write+0x40/0x8c) (ksys_write) from [<c0101000>] (ret_fast_syscall+0x0/0x28) Undefined instruction is triggered during CP14 reset, because bits: #16 (Secure privileged invasive debug disabled) and #17 (Secure privileged noninvasive debug disable) are set in DSCR. Those bits depend on SPNIDEN and SPIDEN lines, which are provided by Secure JTAG hardware block. That block in turn is powered from cluster 0 (big/Eagle), but the Exynos5422 boots on cluster 1 (LITTLE/KFC). To fix this issue it is enough to turn on the power on the cluster 0 for a while. This lets the Secure JTAG block to propagate the needed signals to LITTLE/KFC cores and change their DSCR. Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Phong Hoang authored
[ Upstream commit 347ab948 ] This patch fixes deadlock warning if removing PWM device when CONFIG_PROVE_LOCKING is enabled. This issue can be reproceduced by the following steps on the R-Car H3 Salvator-X board if the backlight is disabled: # cd /sys/class/pwm/pwmchip0 # echo 0 > export # ls device export npwm power pwm0 subsystem uevent unexport # cd device/driver # ls bind e6e31000.pwm uevent unbind # echo e6e31000.pwm > unbind [ 87.659974] ====================================================== [ 87.666149] WARNING: possible circular locking dependency detected [ 87.672327] 5.0.0 #7 Not tainted [ 87.675549] ------------------------------------------------------ [ 87.681723] bash/2986 is trying to acquire lock: [ 87.686337] 000000005ea0e178 (kn->count#58){++++}, at: kernfs_remove_by_name_ns+0x50/0xa0 [ 87.694528] [ 87.694528] but task is already holding lock: [ 87.700353] 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.707405] [ 87.707405] which lock already depends on the new lock. [ 87.707405] [ 87.715574] [ 87.715574] the existing dependency chain (in reverse order) is: [ 87.723048] [ 87.723048] -> #1 (pwm_lock){+.+.}: [ 87.728017] __mutex_lock+0x70/0x7e4 [ 87.732108] mutex_lock_nested+0x1c/0x24 [ 87.736547] pwm_request_from_chip.part.6+0x34/0x74 [ 87.741940] pwm_request_from_chip+0x20/0x40 [ 87.746725] export_store+0x6c/0x1f4 [ 87.750820] dev_attr_store+0x18/0x28 [ 87.754998] sysfs_kf_write+0x54/0x64 [ 87.759175] kernfs_fop_write+0xe4/0x1e8 [ 87.763615] __vfs_write+0x40/0x184 [ 87.767619] vfs_write+0xa8/0x19c [ 87.771448] ksys_write+0x58/0xbc [ 87.775278] __arm64_sys_write+0x18/0x20 [ 87.779721] el0_svc_common+0xd0/0x124 [ 87.783986] el0_svc_compat_handler+0x1c/0x24 [ 87.788858] el0_svc_compat+0x8/0x18 [ 87.792947] [ 87.792947] -> #0 (kn->count#58){++++}: [ 87.798260] lock_acquire+0xc4/0x22c [ 87.802353] __kernfs_remove+0x258/0x2c4 [ 87.806790] kernfs_remove_by_name_ns+0x50/0xa0 [ 87.811836] remove_files.isra.1+0x38/0x78 [ 87.816447] sysfs_remove_group+0x48/0x98 [ 87.820971] sysfs_remove_groups+0x34/0x4c [ 87.825583] device_remove_attrs+0x6c/0x7c [ 87.830197] device_del+0x11c/0x33c [ 87.834201] device_unregister+0x14/0x2c [ 87.838638] pwmchip_sysfs_unexport+0x40/0x4c [ 87.843509] pwmchip_remove+0xf4/0x13c [ 87.847773] rcar_pwm_remove+0x28/0x34 [ 87.852039] platform_drv_remove+0x24/0x64 [ 87.856651] device_release_driver_internal+0x18c/0x21c [ 87.862391] device_release_driver+0x14/0x1c [ 87.867175] unbind_store+0xe0/0x124 [ 87.871265] drv_attr_store+0x20/0x30 [ 87.875442] sysfs_kf_write+0x54/0x64 [ 87.879618] kernfs_fop_write+0xe4/0x1e8 [ 87.884055] __vfs_write+0x40/0x184 [ 87.888057] vfs_write+0xa8/0x19c [ 87.891887] ksys_write+0x58/0xbc [ 87.895716] __arm64_sys_write+0x18/0x20 [ 87.900154] el0_svc_common+0xd0/0x124 [ 87.904417] el0_svc_compat_handler+0x1c/0x24 [ 87.909289] el0_svc_compat+0x8/0x18 [ 87.913378] [ 87.913378] other info that might help us debug this: [ 87.913378] [ 87.921374] Possible unsafe locking scenario: [ 87.921374] [ 87.927286] CPU0 CPU1 [ 87.931808] ---- ---- [ 87.936331] lock(pwm_lock); [ 87.939293] lock(kn->count#58); [ 87.945120] lock(pwm_lock); [ 87.950599] lock(kn->count#58); [ 87.953908] [ 87.953908] *** DEADLOCK *** [ 87.953908] [ 87.959821] 4 locks held by bash/2986: [ 87.963563] #0: 00000000ace7bc30 (sb_writers#6){.+.+}, at: vfs_write+0x188/0x19c [ 87.971044] #1: 00000000287991b2 (&of->mutex){+.+.}, at: kernfs_fop_write+0xb4/0x1e8 [ 87.978872] #2: 00000000f739d016 (&dev->mutex){....}, at: device_release_driver_internal+0x40/0x21c [ 87.988001] #3: 000000006313b17c (pwm_lock){+.+.}, at: pwmchip_remove+0x28/0x13c [ 87.995481] [ 87.995481] stack backtrace: [ 87.999836] CPU: 0 PID: 2986 Comm: bash Not tainted 5.0.0 #7 [ 88.005489] Hardware name: Renesas Salvator-X board based on r8a7795 ES1.x (DT) [ 88.012791] Call trace: [ 88.015235] dump_backtrace+0x0/0x190 [ 88.018891] show_stack+0x14/0x1c [ 88.022204] dump_stack+0xb0/0xec [ 88.025514] print_circular_bug.isra.32+0x1d0/0x2e0 [ 88.030385] __lock_acquire+0x1318/0x1864 [ 88.034388] lock_acquire+0xc4/0x22c [ 88.037958] __kernfs_remove+0x258/0x2c4 [ 88.041874] kernfs_remove_by_name_ns+0x50/0xa0 [ 88.046398] remove_files.isra.1+0x38/0x78 [ 88.050487] sysfs_remove_group+0x48/0x98 [ 88.054490] sysfs_remove_groups+0x34/0x4c [ 88.058580] device_remove_attrs+0x6c/0x7c [ 88.062671] device_del+0x11c/0x33c [ 88.066154] device_unregister+0x14/0x2c [ 88.070070] pwmchip_sysfs_unexport+0x40/0x4c [ 88.074421] pwmchip_remove+0xf4/0x13c [ 88.078163] rcar_pwm_remove+0x28/0x34 [ 88.081906] platform_drv_remove+0x24/0x64 [ 88.085996] device_release_driver_internal+0x18c/0x21c [ 88.091215] device_release_driver+0x14/0x1c [ 88.095478] unbind_store+0xe0/0x124 [ 88.099048] drv_attr_store+0x20/0x30 [ 88.102704] sysfs_kf_write+0x54/0x64 [ 88.106359] kernfs_fop_write+0xe4/0x1e8 [ 88.110275] __vfs_write+0x40/0x184 [ 88.113757] vfs_write+0xa8/0x19c [ 88.117065] ksys_write+0x58/0xbc [ 88.120374] __arm64_sys_write+0x18/0x20 [ 88.124291] el0_svc_common+0xd0/0x124 [ 88.128034] el0_svc_compat_handler+0x1c/0x24 [ 88.132384] el0_svc_compat+0x8/0x18 The sysfs unexport in pwmchip_remove() is completely asymmetric to what we do in pwmchip_add_with_polarity() and commit 0733424c ("pwm: Unexport children before chip removal") is a strong indication that this was wrong to begin with. We should just move pwmchip_sysfs_unexport() where it belongs, which is right after pwmchip_sysfs_unexport_children(). In that case, we do not need separate functions anymore either. We also really want to remove sysfs irrespective of whether or not the chip will be removed as a result of pwmchip_remove(). We can only assume that the driver will be gone after that, so we shouldn't leave any dangling sysfs files around. This warning disappears if we move pwmchip_sysfs_unexport() to the top of pwmchip_remove(), pwmchip_sysfs_unexport_children(). That way it is also outside of the pwm_lock section, which indeed doesn't seem to be needed. Moving the pwmchip_sysfs_export() call outside of that section also seems fine and it'd be perfectly symmetric with pwmchip_remove() again. So, this patch fixes them. Signed-off-by:
Phong Hoang <phong.hoang.wz@renesas.com> [shimoda: revise the commit log and code] Fixes: 76abbdde ("pwm: Add sysfs interface") Fixes: 0733424c ("pwm: Unexport children before chip removal") Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by:
Hoan Nguyen An <na-hoan@jinso.co.jp> Reviewed-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Krzysztof Kozlowski authored
[ Upstream commit 5ab99cf7 ] The PVDD_APIO_1V8 (LDO2) and PVDD_ABB_1V8 (LDO8) regulators were turned off by Linux kernel as unused. However they supply critical parts of SoC so they should be always on: 1. PVDD_APIO_1V8 supplies SYS pins (gpx[0-3], PSHOLD), HDMI level shift, RTC, VDD1_12 (DRAM internal 1.8 V logic), pull-up for PMIC interrupt lines, TTL/UARTR level shift, reset pins and SW-TACT1 button. It also supplies unused blocks like VDDQ_SRAM (for SROM controller) and VDDQ_GPIO (gpm7, gpy7). The LDO2 cannot be turned off (S2MPS11 keeps it on anyway) so marking it "always-on" only reflects its real status. 2. PVDD_ABB_1V8 supplies Adaptive Body Bias Generator for ARM cores, memory and Mali (G3D). Signed-off-by:
-
Sakari Ailus authored
[ Upstream commit 9d386373 ] The lack of defaults provided by the caller to v4l2_fwnode_endpoint_parse() signals the use of the default lane mapping. The default lane mapping must not be used however if the firmmare contains the lane mapping. Disable the default lane mapping in that case, and improve the debug messages telling of the use of the defaults. This was missed previously since the default mapping will only unsed in this case if the bus type is set, and no driver did both while still needing the lane mapping configuration. Fixes: b4357d21 ("media: v4l: fwnode: Support default CSI-2 lane mapping for drivers") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Christoph Vogtländer authored
[ Upstream commit b00ef530 ] It must be made sure that immediate mode is not already set, when modifying shadow register value in ehrpwm_pwm_disable(). Otherwise modifications to the action-qualifier continuous S/W force register(AQSFRC) will be done in the active register. This may happen when both channels are being disabled. In this case, only the first channel state will be recorded as disabled in the shadow register. Later, when enabling the first channel again, the second channel would be enabled as well. Setting RLDCSF to zero, first, ensures that the shadow register is updated as desired. Fixes: 38dabd91 ("pwm: tiehrpwm: Fix disabling of output of PWMs") Signed-off-by:
Christoph Vogtländer <c.vogtlaender@sigma-surface-science.com> [vigneshr@ti.com: Improve commit message] Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 5ba846b1 ] Intel IOMMU, when enabled, tries to find the domain of the device, assuming it's a PCI one, during DMA operations, such as mapping or unmapping. Since we are splitting the actual PCI device to couple of children via MFD framework (see drivers/mfd/intel-lpss.c for details), the DMA device appears to be a platform one, and thus not an actual one that performs DMA. In a such situation IOMMU can't find or allocate a proper domain for its operations. As a result, all DMA operations are failed. In order to fix this, supply parent of the platform device to the DMA engine framework and fix filter functions accordingly. We may rely on the fact that parent is a real PCI device, because no other configuration is present in the wild. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Mark Brown <broonie@kernel.org> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> [for tty parts] Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Christopher N Bednarz authored
[ Upstream commit b58dafbc ] LB_EN for prune switch rules was causing all TX traffic to loopback to the internal switch and dropped. When running bi-directional stress workloads with RDMA the RDPU would hang blocking tx and rx traffic. Signed-off-by:
Christopher N Bednarz <christopher.n.bednarz@intel.com> Reviewed-by:
Bruce Allan <bruce.w.allan@intel.com> Signed-off-by:
Anirudh Venkataramanan <anirudh.venkataramanan@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
-
[ Upstream commit 277b3a45 ] In VEB mode, enable LAN_EN bit in the action fields for filter rules corresponding to the right recipes. Signed-off-by:
Yashaswini Raghuram Prathivadi Bhayankaram <yashaswini.raghuram.prathivadi.bhayankaram@intel.com> Reviewed-by:
-
Sven Eckelmann authored
[ Upstream commit c2d8b9a6 ] The send functions in batman-adv are expected to consume the skb when either the data is queued up for the underlying driver or when some precondition failed. batadv_dat_send_data didn't do this and instead created a copy of the skb, modified it and queued the copy up for transmission. The caller has to take care that the skb is handled correctly (for example free'd) when batadv_dat_send_data returns. This unclear behavior already lead to memory leaks in the recent past. Renaming the function to batadv_dat_forward_data should make it easier to identify that the data is forwarded but the skb is not actually send+consumed. Signed-off-by:
Sven Eckelmann <sven@narfation.org> Signed-off-by:
Simon Wunderlich <sw@simonwunderlich.de> Signed-off-by:
-
Dafna Hirschfeld authored
[ Upstream commit 09ca38a5 ] If one of the controls fails to set, then 'v4l2_ctrl_request_setup' immediately returns with the error code. Signed-off-by:
Dafna Hirschfeld <dafna3@gmail.com> Reviewed-by:
Paul Kocialkowski <paul.kocialkowski@bootlin.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
-
