- 13 Dec, 2019 26 commits
-
-
Wen Yang authored
[ Upstream commit a4c2fec1 ] We can't use "adap->dev" after it has been freed. Fixes: 5bf4fa7d ("i2c: break out OF support into separate file") Signed-off-by:
Wen Yang <wenyang@linux.alibaba.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chuhong Yuan authored
[ Upstream commit 3df70afe ] The driver calls release_resource in remove to match request_mem_region in probe, which is incorrect. Fix it by using the right one, release_mem_region. Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit dcb77e4b ] The driver misses calling destroy_workqueue in remove like what is done when probe fails. Add the missed calls to fix it. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Vitaly Kuznetsov authored
[ Upstream commit e37f9f13 ] Glibc-2.30 gained gettid() wrapper, selftests fail to compile: lib/assert.c:58:14: error: static declaration of ‘gettid’ follows non-static declaration 58 | static pid_t gettid(void) | ^~~~~~ In file included from /usr/include/unistd.h:1170, from include/test_util.h:18, from lib/assert.c:10: /usr/include/bits/unistd_ext.h:34:16: note: previous declaration of ‘gettid’ was here 34 | extern __pid_t gettid (void) __THROW; | ^~~~~~ Signed-off-by:
Vitaly Kuznetsov <vkuznets@redhat.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Yunhao Tian authored
[ Upstream commit 0b8e7bbd ] The datasheet of V3s (and various other chips) wrote that TCON0_DCLK_DIV can be >= 1 if only dclk is used, and must >= 6 if dclk1 or dclk2 is used. As currently neither dclk1 nor dclk2 is used (no writes to these bits), let's set minimal division to 1. If this minimal division is 6, some common dot clock frequencies can't be produced (e.g. 30MHz will not be possible and will fallback to 25MHz), which is obviously not an expected behaviour. Signed-off-by:
Yunhao Tian <t123yh@outlook.com> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/linux-arm-kernel/MN2PR08MB57905AD8A00C08DA219377C989760@MN2PR08MB5790.namprd08.prod.outlook.com/Signed-off-by:
-
paulhsia authored
[ Upstream commit f5cdc9d4 ] If the nullity check for `substream->runtime` is outside of the lock region, it is possible to have a null runtime in the critical section if snd_pcm_detach_substream is called right before the lock. Signed-off-by:
paulhsia <paulhsia@chromium.org> Link: https://lore.kernel.org/r/20191112171715.128727-2-paulhsia@chromium.orgSigned-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Alexander Shishkin authored
[ Upstream commit 697d8778 ] Commit: 313ccb96 ("perf: Allocate context task_ctx_data for child event") makes the inherit path skip over the current event in case of task_ctx_data allocation failure. This, however, is inconsistent with allocation failures in perf_event_alloc(), which would abort the fork. Correct this by returning an error code on task_ctx_data allocation failure and failing the fork in that case. Signed-off-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Link: https://lkml.kernel.org/r/20191105075702.60319-1-alexander.shishkin@linux.intel.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Peter Zijlstra authored
[ Upstream commit ff51ff84 ] While seemingly harmless, __sched_fork() does hrtimer_init(), which, when DEBUG_OBJETS, can end up doing allocations. This then results in the following lock order: rq->lock zone->lock.rlock batched_entropy_u64.lock Which in turn causes deadlocks when we do wakeups while holding that batched_entropy lock -- as the random code does. Solve this by moving __sched_fork() out from under rq->lock. This is safe because nothing there relies on rq->lock, as also evident from the other __sched_fork() callsite. Signed-off-by:
-
Pan Bian authored
[ Upstream commit 79aae6ac ] The device md->input is used after it is released. Setting the device data to NULL is unnecessary as the device is never used again. Instead, md->input should be assigned NULL to avoid accessing the freed memory accidently. Besides, checking md->si against NULL is superfluous as it points to a variable address, which cannot be NULL. Signed-off-by:
Pan Bian <bianpan2016@163.com> Link: https://lore.kernel.org/r/1572936379-6423-1-git-send-email-bianpan2016@163.comSigned-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Xiaodong Xu authored
[ Upstream commit 4944a4b1 ] An ESP packet could be decrypted in async mode if the input handler for this packet returns -EINPROGRESS in xfrm_input(). At this moment the device reference in skb is held. Later xfrm_input() will be invoked again to resume the processing. If the transform state is still valid it would continue to release the device reference and there won't be a problem; however if the transform state is not valid when async resumption happens, the packet will be dropped while the device reference is still being held. When the device is deleted for some reason and the reference to this device is not properly released, the kernel will keep logging like: unregister_netdevice: waiting for ppp2 to become free. Usage count = 1 The issue is observed when running IPsec traffic over a PPPoE device based on a bridge interface. By terminating the PPPoE connection on the server end for multiple times, the PPPoE device on the client side will eventually get stuck on the above warning message. This patch will check the async mode first and continue to release device reference in async resumption, before it is dropped due to invalid state. v2: Do not assign address family from outer_mode in the transform if the state is invalid v3: Release device reference in the error path instead of jumping to resume Fixes: 4ce3dbe3 ("xfrm: Fix xfrm_input() to verify state is valid when (encap_type < 0)") Signed-off-by:
Xiaodong Xu <stid.smth@gmail.com> Reported-by:
Bo Chen <chenborfc@163.com> Tested-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Stephan Gerhold authored
[ Upstream commit a71a29f5 ] I2C communication errors (-EREMOTEIO) during the IRQ handler of nxp-nci result in a NULL pointer dereference at the moment: BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 355 Comm: irq/137-nxp-nci Not tainted 5.4.0-rc6 #1 RIP: 0010:skb_queue_tail+0x25/0x50 Call Trace: nci_recv_frame+0x36/0x90 [nci] nxp_nci_i2c_irq_thread_fn+0xd1/0x285 [nxp_nci_i2c] ? preempt_count_add+0x68/0xa0 ? irq_forced_thread_fn+0x80/0x80 irq_thread_fn+0x20/0x60 irq_thread+0xee/0x180 ? wake_threads_waitq+0x30/0x30 kthread+0xfb/0x130 ? irq_thread_check_affinity+0xd0/0xd0 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x40 Afterward the kernel must be rebooted to work properly again. This happens because it attempts to call nci_recv_frame() with skb == NULL. However, unlike nxp_nci_fw_recv_frame(), nci_recv_frame() does not have any NULL checks for skb, causing the NULL pointer dereference. Change the code to call only nxp_nci_fw_recv_frame() in case of an error. Make sure to log it so it is obvious that a communication error occurred. The error above then becomes: nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 nci: __nci_request: wait_for_completion_interruptible_timeout failed 0 nxp-nci_i2c i2c-NXP1001:00: NFC: Read failed with error -121 Fixes: 6be88670 ("NFC: nxp-nci_i2c: Add I2C support to NXP NCI driver") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit 69924b89 ] if the child has been negative and just went positive under us, we want coherent d_is_positive() and ->d_inode. Don't unlock the parent until we'd done that work... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
[ Upstream commit a2ece088 ] Signed-off-by:
-
Mordechay Goodstein authored
[ Upstream commit cb1a4bad ] From gen2 PN is totally offloaded to hardware (also the space for the IV isn't part of the skb). As you can see in mvm/mac80211.c:3545, the MAC for cipher types CCMP/GCMP doesn't set IEEE80211_KEY_FLAG_PUT_IV_SPACE for gen2 NICs. This causes all the AMSDU data to be corrupted with cipher enabled. Signed-off-by:
Mordechay Goodstein <mordechay.goodstein@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Sirong Wang authored
[ Upstream commit 531eb45b ] Size of pointer to buf field of struct hns_roce_hem_chunk should be considered when calculating HNS_ROCE_HEM_CHUNK_LEN, or sg table size will be larger than expected when allocating hem. Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/1572575610-52530-2-git-send-email-liweihang@hisilicon.comSigned-off-by:
Sirong Wang <wangsirong@huawei.com> Signed-off-by:
Weihang Li <liweihang@hisilicon.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Al Viro authored
[ Upstream commit 03ad0d70 ] if the second call of should_expire() in there ends up grabbing and returning a new reference to dentry, we need to drop it before continuing. Signed-off-by:
-
Chuhong Yuan authored
commit 50b2b571 upstream. The driver forgets to call pm_runtime_disable in remove. Add the missed calls to fix it. Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jiangfeng Xiao authored
commit 7d73170e upstream. Doing fuzz test on sbsa uart device, causes a kernel crash due to NULL pointer dereference: ------------[ cut here ]------------ Unable to handle kernel paging request at virtual address fffffffffffffffc pgd = ffffffe331723000 [fffffffffffffffc] *pgd=0000002333595003, *pud=0000002333595003, *pmd=00000 Internal error: Oops: 96000005 [#1] PREEMPT SMP Modules linked in: ping(O) jffs2 rtos_snapshot(O) pramdisk(O) hisi_sfc(O) Drv_Nandc_K(O) Drv_SysCtl_K(O) Drv_SysClk_K(O) bsp_reg(O) hns3(O) hns3_uio_enet(O) hclgevf(O) hclge(O) hnae3(O) mdio_factory(O) mdio_registry(O) mdio_dev(O) mdio(O) hns3_info(O) rtos_kbox_panic(O) uart_suspend(O) rsm(O) stp llc tunnel4 xt_tcpudp ipt_REJECT nf_reject_ipv4 iptable_filter ip_tables x_tables sd_mod xhci_plat_hcd xhci_pci xhci_hcd usbmon usbhid usb_storage ohci_platform ohci_pci ohci_hcd hid_generic hid ehci_platform ehci_pci ehci_hcd vfat fat usbcore usb_common scsi_mod yaffs2multi(O) ext4 jbd2 ext2 mbcache ofpart i2c_dev i2c_core uio ubi nand nand_ecc nand_ids cfi_cmdset_0002 cfi_cmdset_0001 cfi_probe gen_probe cmdlinepart chipreg mtdblock mtd_blkdevs mtd nfsd auth_rpcgss oid_registry nfsv3 nfs nfs_acl lockd sunrpc grace autofs4 CPU: 2 PID: 2385 Comm: tty_fuzz_test Tainted: G O 4.4.193 #1 task: ffffffe32b23f110 task.stack: ffffffe32bda4000 PC is at uart_break_ctl+0x44/0x84 LR is at uart_break_ctl+0x34/0x84 pc : [<ffffff8393196098>] lr : [<ffffff8393196088>] pstate: 80000005 sp : ffffffe32bda7cc0 x29: ffffffe32bda7cc0 x28: ffffffe32b23f110 x27: ffffff8393402000 x26: 0000000000000000 x25: ffffffe32b233f40 x24: ffffffc07a8ec680 x23: 0000000000005425 x22: 00000000ffffffff x21: ffffffe33ed73c98 x20: 0000000000000000 x19: ffffffe33ed94168 x18: 0000000000000004 x17: 0000007f92ae9d30 x16: ffffff8392fa6064 x15: 0000000000000010 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000020 x10: 0000007ffdac1708 x9 : 0000000000000078 x8 : 000000000000001d x7 : 0000000052a64887 x6 : ffffffe32bda7e08 x5 : ffffffe32b23c000 x4 : 0000005fbc5b0000 x3 : ffffff83938d5018 x2 : 0000000000000080 x1 : ffffffe32b23c040 x0 : ffffff83934428f8 virtual start addr offset is 38ac00000 module base offset is 2cd4cf1000 linear region base offset is : 0 Process tty_fuzz_test (pid: 2385, stack limit = 0xffffffe32bda4000) Stack: (0xffffffe32bda7cc0 to 0xffffffe32bda8000) 7cc0: ffffffe32bda7cf0 ffffff8393177718 ffffffc07a8ec680 ffffff8393196054 7ce0: 000000001739f2e0 0000007ffdac1978 ffffffe32bda7d20 ffffff8393179a1c 7d00: 0000000000000000 ffffff8393c0a000 ffffffc07a8ec680 cb88537fdc8ba600 7d20: ffffffe32bda7df0 ffffff8392fa5a40 ffffff8393c0a000 0000000000005425 7d40: 0000007ffdac1978 ffffffe32b233f40 ffffff8393178dcc 0000000000000003 7d60: 000000000000011d 000000000000001d ffffffe32b23f110 000000000000029e 7d80: ffffffe34fe8d5d0 0000000000000000 ffffffe32bda7e14 cb88537fdc8ba600 7da0: ffffffe32bda7e30 ffffff8393042cfc ffffff8393c41720 ffffff8393c46410 7dc0: ffffff839304fa68 ffffffe32b233f40 0000000000005425 0000007ffdac1978 7de0: 000000000000011d cb88537fdc8ba600 ffffffe32bda7e70 ffffff8392fa60cc 7e00: 0000000000000000 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e20: 0000000000005425 0000007ffdac1978 ffffffe32bda7e70 ffffff8392fa60b0 7e40: 0000000000000280 ffffffe32b233f40 ffffffe32b233f40 0000000000000003 7e60: 0000000000005425 cb88537fdc8ba600 0000000000000000 ffffff8392e02e78 7e80: 0000000000000280 0000005fbc5b0000 ffffffffffffffff 0000007f92ae9d3c 7ea0: 0000000060000000 0000000000000015 0000000000000003 0000000000005425 7ec0: 0000007ffdac1978 0000000000000000 00000000a54c910e 0000007f92b95014 7ee0: 0000007f92b95090 0000000052a64887 000000000000001d 0000000000000078 7f00: 0000007ffdac1708 0000000000000020 0000000000000000 0000000000000000 7f20: 0000000000000000 0000000000000010 000000556acf0090 0000007f92ae9d30 7f40: 0000000000000004 000000556acdef10 0000000000000000 000000556acdebd0 7f60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 7f80: 0000000000000000 0000000000000000 0000000000000000 0000007ffdac1840 7fa0: 000000556acdedcc 0000007ffdac1840 0000007f92ae9d3c 0000000060000000 7fc0: 0000000000000000 0000000000000000 0000000000000003 000000000000001d 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 Call trace: Exception stack(0xffffffe32bda7ab0 to 0xffffffe32bda7bf0) 7aa0: 0000000000001000 0000007fffffffff 7ac0: ffffffe32bda7cc0 ffffff8393196098 0000000080000005 0000000000000025 7ae0: ffffffe32b233f40 ffffff83930d777c ffffffe32bda7b30 ffffff83930d777c 7b00: ffffffe32bda7be0 ffffff83938d5000 ffffffe32bda7be0 ffffffe32bda7c20 7b20: ffffffe32bda7b60 ffffff83930d777c ffffffe32bda7c10 ffffff83938d5000 7b40: ffffffe32bda7c10 ffffffe32bda7c50 ffffff8393c0a000 ffffffe32b23f110 7b60: ffffffe32bda7b70 ffffff8392e09df4 ffffffe32bda7bb0 cb88537fdc8ba600 7b80: ffffff83934428f8 ffffffe32b23c040 0000000000000080 ffffff83938d5018 7ba0: 0000005fbc5b0000 ffffffe32b23c000 ffffffe32bda7e08 0000000052a64887 7bc0: 000000000000001d 0000000000000078 0000007ffdac1708 0000000000000020 7be0: 0000000000000000 0000000000000000 [<ffffff8393196098>] uart_break_ctl+0x44/0x84 [<ffffff8393177718>] send_break+0xa0/0x114 [<ffffff8393179a1c>] tty_ioctl+0xc50/0xe84 [<ffffff8392fa5a40>] do_vfs_ioctl+0xc4/0x6e8 [<ffffff8392fa60cc>] SyS_ioctl+0x68/0x9c [<ffffff8392e02e78>] __sys_trace_return+0x0/0x4 Code: b9410ea0 34000160 f9408aa0 f9402814 (b85fc280) ---[ end trace 8606094f1960c5e0 ]--- Kernel panic - not syncing: Fatal exception Fix this problem by adding NULL checks prior to calling break_ctl ops. Signed-off-by:
Jiangfeng Xiao <xiaojiangfeng@huawei.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/1574263133-28259-1-git-send-email-xiaojiangfeng@huawei.comSigned-off-by:
-
Vincent Whitchurch authored
commit f6a19647 upstream. PL011's ->flush_buffer() implementation releases and reacquires the port lock. Due to a race condition here, data can end up being added to the circular buffer but neither being discarded nor being sent out. This leads to, for example, tcdrain(2) waiting indefinitely. Process A Process B uart_flush_buffer() - acquire lock - circ_clear - pl011_flush_buffer() -- release lock -- dmaengine_terminate_all() uart_write() - acquire lock - add chars to circ buffer - start_tx() -- start DMA - release lock -- acquire lock -- turn off DMA -- release lock // Data in circ buffer but DMA is off According to the comment in the code, the releasing of the lock around dmaengine_terminate_all() is to avoid a deadlock with the DMA engine callback. However, since the time this code was written, the DMA engine API documentation seems to have been clarified to say that dmaengine_terminate_all() (in the identically implemented but differently named dmaengine_terminate_async() variant) does not wait for any running complete callback to be completed and can even be called from a complete callback. So there is no possibility of deadlock if the DMA engine driver implements this API correctly. So we should be able to just remove this release and reacquire of the lock to prevent the aforementioned race condition. Signed-off-by:
Vincent Whitchurch <vincent.whitchurch@axis.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191118092547.32135-1-vincent.whitchurch@axis.comSigned-off-by:
-
Jeffrey Hugo authored
commit b027ce25 upstream. hci_qca interfaces to the wcn3990 via a uart_dm on the msm8998 mtp and Lenovo Miix 630 laptop. As part of initializing the wcn3990, hci_qca disables flow, configures the uart baudrate, and then reenables flow - at which point an event is expected to be received over the uart from the wcn3990. It is observed that this event comes after the baudrate change but before hci_qca re-enables flow. This is unexpected, and is a result of msm_reset() being broken. According to the uart_dm hardware documentation, it is recommended that automatic hardware flow control be enabled by setting RX_RDY_CTL. Auto hw flow control will manage RFR based on the configured watermark. When there is space to receive data, the hw will assert RFR. When the watermark is hit, the hw will de-assert RFR. The hardware documentation indicates that RFR can me manually managed via CR when RX_RDY_CTL is not set. SET_RFR asserts RFR, and RESET_RFR de-asserts RFR. msm_reset() is broken because after resetting the hardware, it unconditionally asserts RFR via SET_RFR. This enables flow regardless of the current configuration, and would undo a previous flow disable operation. It should instead de-assert RFR via RESET_RFR to block flow until the hardware is reconfigured. msm_serial should rely on the client to specify that flow should be enabled, either via mctrl() or the termios structure, and only assert RFR in response to those triggers. Fixes: 04896a77 ("msm_serial: serial driver for MSM7K onboard serial peripheral.") Signed-off-by:
Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Cc: stable <stable@vger.kernel.org> Reviewed-by:
Andy Gross <agross@kernel.org> Link: https://lore.kernel.org/r/20191021154616.25457-1-jeffrey.l.hugo@gmail.comSigned-off-by:
-
Peng Fan authored
commit 487ee861 upstream. The dmaengine_prep_slave_sg needs to use sg count returned by dma_map_sg, not use sport->dma_tx_nents, because the return value of dma_map_sg is not always same with "nents". When enabling iommu for lpuart + edma, iommu framework may concatenate two sgs into one. Fixes: 6250cc30 ("tty: serial: fsl_lpuart: Use scatter/gather DMA for Tx") Cc: <stable@vger.kernel.org> Signed-off-by:
Peng Fan <peng.fan@nxp.com> Link: https://lore.kernel.org/r/1572932977-17866-1-git-send-email-peng.fan@nxp.comSigned-off-by:
-
Michał Mirosław authored
commit daf82bd2 upstream. gserial_alloc_line() misses locking (for a release barrier) while resetting port entry on TTY allocation failure. Fix this. Cc: stable@vger.kernel.org Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Reviewed-by:
Ladislav Michl <ladis@linux-mips.org> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
commit 45a2d646 upstream. The layout of struct timeval is different on sparc64 from anything else, and the patch I did long ago failed to take this into account. Change it now to handle sparc64 user space correctly again. Quite likely nobody cares about parallel ports on sparc64, but there is no reason not to fix it. Cc: stable@vger.kernel.org Fixes: 9a450484 ("lp: support 64-bit time_t user space") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20191108203435.112759-7-arnd@arndb.deSigned-off-by:
-
Tuowen Zhao authored
commit 38e45d81 upstream. On sparc64, the whole physical IO address space is accessible using physically addressed loads and stores. *_uc does nothing like the others. Cc: <stable@vger.kernel.org> # v4.19+ Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Tuowen Zhao <ztuowen@gmail.com> Acked-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Jon Hunter authored
commit 1e5e929c upstream. Commit 34993594 ("arm64: tegra: Enable HDMI on Jetson TX1") added a regulator for HDMI on the Jetson TX1 platform. This regulator has an active high enable, but the GPIO specifier for enabling the regulator incorrectly defines it as active-low. This causes the following warning to occur on boot ... WARNING KERN regulator@10 GPIO handle specifies active low - ignored The fixed-regulator binding does not use the active-low flag from the gpio specifier and purely relies of the presence of the 'enable-active-high' property to determine if it is active high or low (if this property is omitted). Fix this warning by setting the GPIO to active-high in the GPIO specifier which aligns with the presense of the 'enable-active-high' property. Fixes: 34993594 ("arm64: tegra: Enable HDMI on Jetson TX1") Signed-off-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Navid Emamdoost authored
commit d563131e upstream. In rsi_send_beacon, if rsi_prepare_beacon fails the allocated skb should be released. Signed-off-by:
Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by:
-
- 05 Dec, 2019 14 commits
-
-
Greg Kroah-Hartman authored
-
Chuhong Yuan authored
commit a31eda65 upstream. pm_runtime_put_autosuspend in probe will call runtime suspend to disable clks automatically if CONFIG_PM is defined. (If CONFIG_PM is not defined, its implementation will be empty, then runtime suspend will not be called.) Therefore, we can call pm_runtime_get_sync to runtime resume it first to enable clks, which matches the runtime suspend. (Only when CONFIG_PM is defined, otherwise pm_runtime_get_sync will also be empty, then runtime resume will not be called.) Then it is fine to disable clks without causing clock count mis-match. Fixes: c43eab3e ("net: fec: add missed clk_disable_unprepare in remove") Signed-off-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Hans de Goede authored
commit f3e4f3fc upstream. The AML code implementing the WMI methods creates a variable length field to hold the input data we pass like this: CreateDWordField (Arg1, 0x0C, DSZI) Local5 = DSZI /* \HWMC.DSZI */ CreateField (Arg1, 0x80, (Local5 * 0x08), DAIN) If we pass 0 as bios_args.datasize argument then (Local5 * 0x08) is 0 which results in these errors: [ 71.973305] ACPI BIOS Error (bug): Attempt to CreateField of length zero (20190816/dsopcode-133) [ 71.973332] ACPI Error: Aborting method \HWMC due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) [ 71.973413] ACPI Error: Aborting method \_SB.WMID.WMAA due to previous error (AE_AML_OPERAND_VALUE) (20190816/psparse-529) And in our HPWMI_WIRELESS2_QUERY calls always failing. for read commands like HPWMI_WIRELESS2_QUERY the DSZI value is not used / checked, except for read commands where extra input is needed to specify exactly what to read. So for HPWMI_WIRELESS2_QUERY we can safely pass the size of the expected output as insize to hp_wmi_perform_query(), as we are already doing for all other HPWMI_READ commands we send. Doing so fixes these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hans de Goede authored
commit 16245db1 upstream. The HP WMI calls may take up to 128 bytes of data as input, and the AML methods implementing the WMI calls, declare a couple of fields for accessing input in different sizes, specifycally the HWMC method contains: CreateField (Arg1, 0x80, 0x0400, D128) Even though we do not use any of the WMI command-types which need a buffer of this size, the APCI interpreter still tries to create it as it is declared in generoc code at the top of the HWMC method which runs before the code looks at which command-type is requested. This results in many of these errors on many different HP laptop models: [ 14.459261] ACPI Error: Field [D128] at 1152 exceeds Buffer [NULL] size 160 (bits) (20170303/dsopcode-236) [ 14.459268] ACPI Error: Method parse/execution failed [\HWMC] (Node ffff8edcc61507f8), AE_AML_BUFFER_LIMIT (20170303/psparse-543) [ 14.459279] ACPI Error: Method parse/execution failed [\_SB.WMID.WMAA] (Node ffff8edcc61523c0), AE_AML_BUFFER_LIMIT (20170303/psparse-543) This commit increases the size of the data element of the bios_args struct to 128 bytes fixing these errors. Cc: stable@vger.kernel.org BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=197007 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=201981 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1520703Signed-off-by:
-
Pierre-Yves MORDRET authored
commit cc832dc8 upstream. When a period length is not multiple of FIFO some data may be stuck within FIFO. Burst/FIFO Threshold/Period or buffer length check has to be hardened In any case DMA will grant any request from client but will degraded any parameters whether awkward. Signed-off-by:
Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Signed-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Wen Yang authored
commit 1c3816a1 upstream. The of_find_device_by_node() takes a reference to the underlying device structure, we should release that reference. Fixes: 7dd0d835 ("ASoC: stm32: sai: simplify sync modes management") Signed-off-by:
Wen Yang <yellowriver2010@hotmail.com> Acked-by:
Olivier Moysan <olivier.moysan@st.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Olivier Moysan authored
commit 8ba3c521 upstream. Because of regmap cache, interrupts may not be cleared as expected. Declare IFCR register as write only and make writings to IFCR register unconditional. Signed-off-by:
-
Olivier Moysan authored
commit 0c4c68d6 upstream. I2S supports 16 bits data in 32 channel length. However the expected driver behavior, is to set channel length to 16 bits when data format is 16 bits. Signed-off-by:
-
Olivier Moysan authored
commit 1ac2bd16 upstream. DMA configuration is not balanced on start/stop. Move DMA configuration to trigger callback. Signed-off-by:
-
Alexandre Torgue authored
commit cd8c9b5a upstream. configs is allocated by pinconf_generic_parse_dt_config(), pinctrl_utils_add_map_configs() duplicates configs so it can and has to be freed to prevent memory leaks. Signed-off-by:
Alexandre Torgue <alexandre.torgue@st.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Fabien Dessenne authored
commit 6899b4f7 upstream. Fix null pointer issue if resource_size is called with no ioresource. Signed-off-by:
Ludovic Barre <ludovic.barre@st.com> Signed-off-by:
Fabien Dessenne <fabien.dessenne@st.com> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
-
Gabriel Fernandez authored
commit 749c9e55 upstream. Fixes parent clock for axi, fdcan, sai and adc12 clocks. Fixes: e51d297e ("clk: stm32mp1: add Sub System clocks") Signed-off-by:
Gabriel Fernandez <gabriel.fernandez@st.com> Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Gabriel Fernandez authored
commit 72cfd1ad upstream. STM32MP1 clock IP offers lots of Kernel clocks that are shared by multiple IP's at the same time. Then boot loader applies a clock tree that allows to use all IP's at same time and with the maximum of performance. Not change parents on a change rate on kernel clocks ensures the integrity of the system. Signed-off-by:
-
Gabriel Fernandez authored
commit 140fc4e4 upstream. index 8: ck_mcu is divided by 256 (not 512) Fixes: e51d297e ("clk: stm32mp1: add Sub System clocks") Signed-off-by:
-
