- 19 Aug, 2020 40 commits
-
-
Marco Felsch authored
[ Upstream commit 7bb58b98 ] Add missing regulator_disable() as devm_action to avoid dedicated unbind() callback and fix the missing error handling. Fixes: fcbc51e5 ("staging: drm/imx: Add support for Television Encoder (TVEv2)") Signed-off-by:
Marco Felsch <m.felsch@pengutronix.de> Signed-off-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Aneesh Kumar K.V authored
[ Upstream commit d79e7a5f ] We are wrongly using CPU_FTRS_POWER8 to check for P8 support. Instead, we should use PVR value. Now considering we are using CPU_FTRS_POWER8, that implies we returned true for P9 with older firmware. Keep the same behavior by checking for P9 PVR value. Fixes: cf43d3b2 ("powerpc: Enable pkey subsystem") Signed-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20200709032946.881753-2-aneesh.kumar@linux.ibm.comSigned-off-by:
-
Xiongfeng Wang authored
[ Upstream commit 3167e3d3 ] When I cat ASPM parameter 'policy' by sysfs, it displays as follows. Add a newline for easy reading. Other sysfs attributes already include a newline. [root@localhost ~]# cat /sys/module/pcie_aspm/parameters/policy [default] performance powersave powersupersave [root@localhost ~]# Fixes: 7d715a6c ("PCI: add PCI Express ASPM support") Link: https://lore.kernel.org/r/1594972765-10404-1-git-send-email-wangxiongfeng2@huawei.comSigned-off-by:
Xiongfeng Wang <wangxiongfeng2@huawei.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit c4283950 ] Currently the masking of ret with 0xff and followed by a right shift of 8 bits always leaves a zero result. It appears the mask of 0xff is incorrect and should be 0xff00, but I don't have the hardware to test this. Fix this to mask the upper 8 bits before shifting. [ Not tested ] Addresses-Coverity: ("Operands don't affect result") Fixes: 8fc8598e ("Staging: Added Realtek rtl8192u driver to staging") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mikhail Malygin authored
[ Upstream commit 5f0b2a60 ] rxe_post_send_kernel() iterates over linked list of wr's, until the wr->next ptr is NULL. However if we've got an interrupt after last wr is posted, control may be returned to the code after send completion callback is executed and wr memory is freed. As a result, wr->next pointer may contain incorrect value leading to panic. Store the wr->next on the stack before posting it. Fixes: 8700e3e7 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200716190340.23453-1-m.malygin@yadro.comSigned-off-by:
Mikhail Malygin <m.malygin@yadro.com> Signed-off-by:
Sergey Kojushev <s.kojushev@yadro.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Signed-off-by:
-
Yuval Basson authored
[ Upstream commit acca72e2 ] QP's with the same SRQ, working on different CQs and running in parallel on different CPUs could lead to a race when maintaining the SRQ consumer count, and leads to FW running out of SRQs. Update the consumer atomically. Make sure the wqe_prod is updated after the sge_prod due to FW requirements. Fixes: 3491c9e7 ("qedr: Add support for kernel mode SRQ's") Link: https://lore.kernel.org/r/20200708195526.31040-1-ybason@marvell.comSigned-off-by:
Michal Kalderon <mkalderon@marvell.com> Signed-off-by:
Yuval Basson <ybason@marvell.com> Signed-off-by:
-
Milton Miller authored
[ Upstream commit a9f675f9 ] The code in vdso_cpu_init that exposes the cpu and numa node to userspace via SPRG_VDSO incorrctly masks the cpu to 12 bits. This means that any kernel running on a box with more than 4096 threads (NR_CPUS advertises a limit of of 8192 cpus) would expose userspace to two cpu contexts running at the same time with the same cpu number. Note: I'm not aware of any distro shipping a kernel with support for more than 4096 threads today, nor of any system image that currently exceeds 4096 threads. Found via code browsing. Fixes: 18ad51dd ("powerpc: Add VDSO version of getcpu") Signed-off-by:
Milton Miller <miltonm@us.ibm.com> Signed-off-by:
Anton Blanchard <anton@linux.ibm.com> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit e1869678 ] The length of the key comes from the network and it's a 16 bit number. It needs to be capped to prevent a buffer overflow. Fixes: 5e6e3a92 ("wireless: mwifiex: initial commit for Marvell mwifiex driver") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Ganapathi Bhat <ganapathi.bhat@nxp.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20200708115857.GA13729@mwandaSigned-off-by:
-
John Garry authored
[ Upstream commit c87bf24c ] sdebug_max_queue should not exceed SDEBUG_CANQUEUE, otherwise crashes like this can be triggered by passing an out-of-range value: Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019 pstate: 20400009 (nzCv daif +PAN -UAO BTYPE=--) pc : schedule_resp+0x2a4/0xa70 [scsi_debug] lr : schedule_resp+0x52c/0xa70 [scsi_debug] sp : ffff800022ab36f0 x29: ffff800022ab36f0 x28: ffff0023a935a610 x27: ffff800008e0a648 x26: 0000000000000003 x25: ffff0023e84f3200 x24: 00000000003d0900 x23: 0000000000000000 x22: 0000000000000000 x21: ffff0023be60a320 x20: ffff0023be60b538 x19: ffff800008e13000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000001 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 00000000000000c1 x5 : 0000020000200000 x4 : dead0000000000ff x3 : 0000000000000200 x2 : 0000000000000200 x1 : ffff800008e13d88 x0 : 0000000000000000 Call trace: schedule_resp+0x2a4/0xa70 [scsi_debug] scsi_debug_queuecommand+0x2c4/0x9e0 [scsi_debug] scsi_queue_rq+0x698/0x840 __blk_mq_try_issue_directly+0x108/0x228 blk_mq_request_issue_directly+0x58/0x98 blk_mq_try_issue_list_directly+0x5c/0xf0 blk_mq_sched_insert_requests+0x18c/0x200 blk_mq_flush_plug_list+0x11c/0x190 blk_flush_plug_list+0xdc/0x110 blk_finish_plug+0x38/0x210 blkdev_direct_IO+0x450/0x4d8 generic_file_read_iter+0x84/0x180 blkdev_read_iter+0x3c/0x50 aio_read+0xc0/0x170 io_submit_one+0x5c8/0xc98 __arm64_sys_io_submit+0x1b0/0x258 el0_svc_common.constprop.3+0x68/0x170 do_el0_svc+0x24/0x90 el0_sync_handler+0x13c/0x1a8 el0_sync+0x158/0x180 Code: 528847e0 72a001e0 6b00003f 540018cd (3941c340) In addition, it should not be less than 1. So add checks for these, and fail the module init for those cases. [mkp: changed if condition to match error message] Link: https://lore.kernel.org/r/1594297400-24756-2-git-send-email-john.garry@huawei.com Fixes: c4837394 ("scsi_debug: add multiple queue support") Reviewed-by:
Ming Lei <ming.lei@redhat.com> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
John Garry <john.garry@huawei.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Tom Rix authored
[ Upstream commit 02cd2d31 ] clang static analysis flags this error sil-sii8620.c:184:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return ret; ^~~~~~~~~~ sii8620_readb calls sii8620_read_buf. sii8620_read_buf can return without setting its output pararmeter 'ret'. So initialize ret. Fixes: ce6e153f ("drm/bridge: add Silicon Image SiI8620 driver") Signed-off-by:
Tom Rix <trix@redhat.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200712152453.27510-1-trix@redhat.comSigned-off-by:
-
Marek Szyprowski authored
[ Upstream commit dcbabfeb ] PHY calibration is needed only for USB2.0 (UTMI) PHY, so skip calling calibration code when phy_calibrate() is called for USB3.0 (PIPE3) PHY. Fixes: d8c80bb3 ("phy: exynos5-usbdrd: Calibrate LOS levels for exynos5420/5800") Signed-off-by:
Marek Szyprowski <m.szyprowski@samsung.com> Acked-by:
Krzysztof Kozlowski <krzk@kernel.org> Link: https://lore.kernel.org/r/20200708133800.3336-1-m.szyprowski@samsung.comSigned-off-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Laurent Pinchart authored
[ Upstream commit a6ae2fe5 ] The LG LB070WV8 panel incorrectly reports a 16 bits per component value, while the panel uses 8 bits per component. Fix it. Fixes: dd015002 ("drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel") Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
-
Kai-Heng Feng authored
[ Upstream commit 302a085c ] Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon system suspend. led_set_brightness_nopm() uses schedule_work() to set LED brightness. However, there's no guarantee that the scheduled work gets executed because no one flushes the work. So flush the scheduled work to make sure LED gets turned off. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Acked-by:
Jacek Anaszewski <jacek.anaszewski@gmail.com> Fixes: 81fe8e5b ("leds: core: Add led_set_brightness_nosleep{nopm} functions") Signed-off-by:
Pavel Machek <pavel@ucw.cz> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit 2a7e32d0 ] The pci_cfg_wait queue is used to prevent user-space config accesses to devices while they are recovering from reset. Previously we used these operations on pci_cfg_wait: __add_wait_queue(&pci_cfg_wait, ...) __remove_wait_queue(&pci_cfg_wait, ...) wake_up_all(&pci_cfg_wait) The wake_up acquires the wait queue lock, but the add and remove do not. Originally these were all protected by the pci_lock, but cdcb33f9 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock"), moved wake_up_all() outside pci_lock, so it could race with add/remove operations, which caused occasional kernel panics, e.g., during vfio-pci hotplug/unplug testing: Unable to handle kernel read from unreadable memory at virtual address ffff802dac469000 Resolve this by using wait_event() instead of __add_wait_queue() and __remove_wait_queue(). The wait queue lock is held by both wait_event() and wake_up_all(), so it provides mutual exclusion. Fixes: cdcb33f9 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock") Link: https://lore.kernel.org/linux-pci/79827f2f-9b43-4411-1376-b9063b67aee3@huawei.com/T/#u Based-on: https://lore.kernel.org/linux-pci/20191210031527.40136-1-zhengxiang9@huawei.com/Based-on-patch-by:
Xiang Zheng <zhengxiang9@huawei.com> Signed-off-by:
-
Zhu Yanjun authored
[ Upstream commit 5c99274b ] In the loopback tests, the following call trace occurs. Call Trace: __rxe_do_task+0x1a/0x30 [rdma_rxe] rxe_qp_destroy+0x61/0xa0 [rdma_rxe] rxe_destroy_qp+0x20/0x60 [rdma_rxe] ib_destroy_qp_user+0xcc/0x220 [ib_core] uverbs_free_qp+0x3c/0xc0 [ib_uverbs] destroy_hw_idr_uobject+0x24/0x70 [ib_uverbs] uverbs_destroy_uobject+0x43/0x1b0 [ib_uverbs] uobj_destroy+0x41/0x70 [ib_uverbs] __uobj_get_destroy+0x39/0x70 [ib_uverbs] ib_uverbs_destroy_qp+0x88/0xc0 [ib_uverbs] ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xb9/0xf0 [ib_uverbs] ib_uverbs_cmd_verbs+0xb16/0xc30 [ib_uverbs] The root cause is that the actual RDMA connection is not created in the loopback tests and the rxe_match_dgid will fail randomly. To fix this call trace which appear in the loopback tests, skip check of the dgid. Fixes: 8700e3e7 ("Soft RoCE driver") Link: https://lore.kernel.org/r/20200630123605.446959-1-leon@kernel.orgSigned-off-by:
Zhu Yanjun <yanjunz@mellanox.com> Signed-off-by:
Leon Romanovsky <leonro@mellanox.com> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 83895227 ] Quota reservations are supposed to account for the blocks that might be allocated due to a bmap btree split. Reflink doesn't do this, so fix this to make the quota accounting more accurate before we start rearranging things. Fixes: 862bb360 ("xfs: reflink extents from one file to another") Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit eb0efe50 ] The data fork scrubber calls filemap_write_and_wait to flush dirty pages and delalloc reservations out to disk prior to checking the data fork's extent mappings. Unfortunately, this means that scrub can consume the EIO/ENOSPC errors that would otherwise have stayed around in the address space until (we hope) the writer application calls fsync to persist data and collect errors. The end result is that programs that wrote to a file might never see the error code and proceed as if nothing were wrong. xfs_scrub is not in a position to notify file writers about the writeback failure, and it's only here to check metadata, not file contents. Therefore, if writeback fails, we should stuff the error code back into the address space so that an fsync by the writer application can pick that up. Fixes: 99d9d8d0 ("xfs: scrub inode block mappings") Signed-off-by:
Dave Chinner <dchinner@redhat.com> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit 18ffec75 ] fimc_md_get_pinctrl() misses a check for pinctrl_lookup_state(). Add the missed check to fix it. Fixes: 4163851f ("[media] s5p-fimc: Use pinctrl API for camera ports configuration]") Signed-off-by:
Chuhong Yuan <hslester96@gmail.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 2505a210 ] If fw_csr_string() returns -ENOENT, then "name" is uninitialized. So then the "strlen(model_names[i]) <= name_len" is true because strlen() is unsigned and -ENOENT is type promoted to a very high positive value. Then the "strncmp(name, model_names[i], name_len)" uses uninitialized data because "name" is uninitialized. Fixes: 92374e88 ("[media] firedtv: drop obsolete backend abstraction") Signed-off-by:
-
Julian Anastasov authored
[ Upstream commit f0a5e4d7 ] YangYuxi is reporting that connection reuse is causing one-second delay when SYN hits existing connection in TIME_WAIT state. Such delay was added to give time to expire both the IPVS connection and the corresponding conntrack. This was considered a rare case at that time but it is causing problem for some environments such as Kubernetes. As nf_conntrack_tcp_packet() can decide to release the conntrack in TIME_WAIT state and to replace it with a fresh NEW conntrack, we can use this to allow rescheduling just by tuning our check: if the conntrack is confirmed we can not schedule it to different real server and the one-second delay still applies but if new conntrack was created, we are free to select new real server without any delays. YangYuxi lists some of the problem reports: - One second connection delay in masquerading mode: https://marc.info/?t=151683118100004&r=1&w=2 - IPVS low throughput #70747 https://github.com/kubernetes/kubernetes/issues/70747 - Apache Bench can fill up ipvs service proxy in seconds #544 https://github.com/cloudnativelabs/kube-router/issues/544 - Additional 1s latency in `host -> service IP -> pod` https://github.com/kubernetes/kubernetes/issues/90854 Fixes: f719e375 ("ipvs: drop first packet to redirect conntrack") Co-developed-by:
YangYuxi <yx.atom1@gmail.com> Signed-off-by:
Julian Anastasov <ja@ssi.bg> Reviewed-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 86f2da11 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200626040553.944352-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit d179f7c7 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200626035948.944148-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 7ee78aff ] There is an off-by-one bounds check on the index into arrays table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that can lead to reads and writes outside of arrays. Fix the bound checking off-by-one error. Addresses-Coverity: ("Out-of-bounds read/write") Fixes: cc8dbbb4 ("drm/radeon: add dpm support for CI dGPUs (v2)") Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Wang Hai authored
[ Upstream commit 85c5cbeb ] Currently the error return path from kobject_init_and_add() is not followed by a call to kobject_put() - which means we are leaking the kobject. Fix it by adding a call to kobject_put() in the error path of kobject_init_and_add(). Fixes: b087e619 ("cxl: Export optional AFU configuration record in sysfs") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Acked-by:
Andrew Donnellan <ajd@linux.ibm.com> Acked-by:
Frederic Barrat <fbarrat@linux.ibm.com> Link: https://lore.kernel.org/r/20200602120733.5943-1-wanghai38@huawei.comSigned-off-by:
-
Emil Velikov authored
[ Upstream commit 7a05c3b6 ] The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently using the generic write. This does not look right. Perhaps some platforms don't distinguish between the two writers? Cc: Robert Chiras <robert.chiras@nxp.com> Cc: Vinay Simha BN <simhavcs@gmail.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Thierry Reding <treding@nvidia.com> Fixes: e8395081 ("drm/dsi: Implement set tear scanline") Signed-off-by:
Emil Velikov <emil.velikov@collabora.com> Reviewed-by:
Thierry Reding <treding@nvidia.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 040ab9c4 ] The dev_id used in request_irq() and free_irq() should match. Use 'info' in both cases. Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr Fixes: 1da177e4 ("Linux-2.6.12-rc2") Acked-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 88cee34b ] This field is required for ASoC cards. Not setting it will result in a module->name pointer being NULL and generate problems such as cat /proc/asound/modules 0 (efault) Fixes: 76016322 ('ASoC: Intel: Add Broxton-P machine driver') Reported-by:
Jaroslav Kysela <perex@perex.cz> Suggested-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20200625191308.3322-5-pierre-louis.bossart@linux.intel.comSigned-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Chuhong Yuan authored
[ Upstream commit dc7690a7 ] preview_init_entities() does not call v4l2_ctrl_handler_free() when it fails. Add the missed function to fix it. Fixes: de1135d4 ("[media] omap3isp: CCDC, preview engine and resizer") Signed-off-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 985b1f59 ] clang points out that doing arithmetic between diffent enums is usually a mistake: drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion] reg_val = pdata->pin_tx2 | pdata->ntc_pin; ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion] reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode; ~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~ In this driver, it is intentional, so add a cast to hide the false-positive warning. It appears to be the only instance of this warning at the moment. Fixes: b98d13c7 ("leds: Add new LED driver for lm355x chips") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 5f368dde ] Shifting the integer value 1 is evaluated using 32-bit arithmetic and then used in an expression that expects a long value leads to a potential integer overflow. Fix this by using the BIT macro to perform the shift to avoid the overflow. Addresses-Coverity: ("Unintentional integer overflow") Fixes: ad49f860 ("drm/arm: Add support for Mali Display Processors") Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Signed-off-by:
-
Lubomir Rintel authored
[ Upstream commit f8794fea ] Since commit 65f037e8 ("drm/etnaviv: add support for slave interface clock") the reg clock is enabled before the bus clock and we need to undo its enablement on error. Fixes: 65f037e8 ("drm/etnaviv: add support for slave interface clock") Signed-off-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Signed-off-by:
-
Tomasz Duszynski authored
[ Upstream commit df16c33a ] IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting raw concentrations of pollutants. Raw value should be meaningless before being properly scaled. Because of that description shouldn't mention raw value unit whatsoever. Fix this by rephrasing existing description so it follows conventions used throughout IIO ABI docs. Fixes: 8ff6b3bc ("iio: chemical: Add IIO_CONCENTRATION channel type") Signed-off-by:
Tomasz Duszynski <tomasz.duszynski@octakon.com> Acked-by:
Matt Ranostay <matt.ranostay@konsulko.com> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Evan Green authored
[ Upstream commit a738e766 ] ath10k_htt_tx_free_msdu_id() has a lockdep assertion that htt->tx_lock is held. Acquire the lock in a couple of error paths when calling that function to ensure this condition is met. Fixes: 6421969f ("ath10k: refactor tx pending management") Fixes: e62ee5c3 ("ath10k: Add support for htt_data_tx_desc_64 descriptor") Signed-off-by:
Evan Green <evgreen@chromium.org> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 499a2c41 ] 'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()' not 'dma_free_wc()'. The correct dma_free_ function is already used in the error handling path of the probe function. Fixes: 77e19675 ("[ARM] pxafb: allow video memory size to be configurable") Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200429084505.108897-1-christophe.jaillet@wanadoo.frSigned-off-by:
-
Dejin Zheng authored
[ Upstream commit fd4b8243 ] A call of the function do_take_over_console() can fail here. The corresponding system resources were not released then. Thus add a call of iounmap() and release_mem_region() together with the check of a failure predicate. and also add release_mem_region() on device removal. Fixes: e86bb8ac ("[PATCH] VT binding: Make newport_con support binding") Suggested-by:
Dejin Zheng <zhengdejin5@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> cc: Thomas Gleixner <tglx@linutronix.de> Cc: Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Dejin Zheng authored
[ Upstream commit 98bd4f72 ] the sfb->fb->screen_base is not save the value get by iounmap() when the chip id is 0x720. so iounmap() for address sfb->fb->screen_base is not right. Fixes: 1461d667 ("staging: sm7xxfb: merge sm712fb with fbdev") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: Teddy Wang <teddy.wang@siliconmotion.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Qiushi Wu authored
[ Upstream commit b975abbd ] In intel_gtt_setup_scratch_page(), pointer "page" is not released if pci_dma_mapping_error() return an error, leading to a memory leak on module initialisation failure. Simply fix this issue by freeing "page" before return. Fixes: 0e87d2b0 ("intel-gtt: initialize our own scratch page") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Rob Clark authored
[ Upstream commit 5e16372b ] This can happen a lot when things go pear shaped. Lets not flood dmesg when this happens. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by:
-
Erik Kaneda authored
[ Upstream commit 6a54ebae ] ACPICA commit e17b28cfcc31918d0db9547b6b274b09c413eb70 Object reference counts are used as a part of ACPICA's garbage collection mechanism. This mechanism keeps track of references to heap-allocated structures such as the ACPI operand objects. Recent server firmware has revealed that this reference count can overflow on large servers that declare many field units under the same operation_region. This occurs because each field unit declaration will add a reference count to the source operation_region. This change solves the reference count overflow for operation_regions objects by preventing fieldunits from incrementing their operation_region's reference count. Each operation_region's reference count will not be changed by named objects declared under the Field operator. During namespace deletion, the operation_region namespace node will be deleted and each fieldunit will be deleted without touching the deleted operation_region object. Link: https://github.com/acpica/acpica/commit/e17b28cfSigned-off-by:
Erik Kaneda <erik.kaneda@intel.com> Signed-off-by:
Bob Moore <robert.moore@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Coly Li authored
[ Upstream commit 117f636e ] In register_cache_set(), c is pointer to struct cache_set, and ca is pointer to struct cache, if ca->sb.seq > c->sb.seq, it means this registering cache has up to date version and other members, the in- memory version and other members should be updated to the newer value. But current implementation makes a cache set only has a single cache device, so the above assumption works well except for a special case. The execption is when a cache device new created and both ca->sb.seq and c->sb.seq are 0, because the super block is never flushed out yet. In the location for the following if() check, 2156 if (ca->sb.seq > c->sb.seq) { 2157 c->sb.version = ca->sb.version; 2158 memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16); 2159 c->sb.flags = ca->sb.flags; 2160 c->sb.seq = ca->sb.seq; 2161 pr_debug("set version = %llu\n", c->sb.version); 2162 } c->sb.version is not initialized yet and valued 0. When ca->sb.seq is 0, the if() check will fail (because both values are 0), and the cache set version, set_uuid, flags and seq won't be updated. The above problem is hiden for current code, because the bucket size is compatible among different super block version. And the next time when running cache set again, ca->sb.seq will be larger than 0 and cache set super block version will be updated properly. But if the large bucket feature is enabled, sb->bucket_size is the low 16bits of the bucket size. For a power of 2 value, when the actual bucket size exceeds 16bit width, sb->bucket_size will always be 0. Then read_super_common() will fail because the if() check to is_power_of_2(sb->bucket_size) is false. This is how the long time hidden bug is triggered. This patch modifies the if() check to the following way, 2156 if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) { Then cache set's version, set_uuid, flags and seq will always be updated corectly including for a new created cache device. Signed-off-by:
Coly Li <colyli@suse.de> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
