summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-30fs: Handle I_DONTCACHE in iput_final() instead of generic_drop_inode()Hao Li2-3/+4
[ Upstream commit 88149082bb8ef31b289673669e080ec6a00c2e59 ] If generic_drop_inode() returns true, it means iput_final() can evict this inode regardless of whether it is dirty or not. If we check I_DONTCACHE in generic_drop_inode(), any inode with this bit set will be evicted unconditionally. This is not the desired behavior because I_DONTCACHE only means the inode shouldn't be cached on the LRU list. As for whether we need to evict this inode, this is what generic_drop_inode() should do. This patch corrects the usage of I_DONTCACHE. This patch was proposed in [1]. [1]: https://lore.kernel.org/linux-fsdevel/20200831003407.GE12096@dread.disaster.area/ Fixes: dae2f8ed7992 ("fs: Lift XFS_IDONTCACHE to the VFS layer") Signed-off-by: Hao Li <lihao2018.fnst@cn.fujitsu.com> Reviewed-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30samples/bpf: Fix possible hang in xdpsock with multiple threadsMagnus Karlsson1-0/+2
[ Upstream commit 092fde0f863b72b67c4d6dc03844f5658fc00a35 ] Fix a possible hang in xdpsock that can occur when using multiple threads. In this case, one or more of the threads might get stuck in the while-loop in tx_only after the user has signaled the main thread to stop execution. In this case, no more Tx packets will be sent, so a thread might get stuck in the aforementioned while-loop. Fix this by introducing a test inside the while-loop to check if the benchmark has been terminated. If so, return from the function. Fixes: cd9e72b6f210 ("samples/bpf: xdpsock: Add option to specify batch size") Signed-off-by: Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20201210163407.22066-1-magnus.karlsson@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30mtd: rawnand: gpmi: Fix the random DMA timeout issueHan Xu1-9/+21
[ Upstream commit 7671edeb193910482a9b0c22cd32176e7de7b2ed ] To get better performance, current gpmi driver collected and chained all small DMA transfers in gpmi_nfc_exec_op, the whole chain triggered and wait for complete at the end. But some random DMA timeout found in this new driver, with the help of ftrace, we found the root cause is as follows: Take gpmi_ecc_read_page() as an example, gpmi_nfc_exec_op collected 6 DMA transfers and the DMA chain triggered at the end. It waits for bch completion and check jiffies if it's timeout. The typical function graph shown below, 63.216351 | 1) | gpmi_ecc_read_page() { 63.216352 | 1) 0.750 us | gpmi_bch_layout_std(); 63.216354 | 1) | gpmi_nfc_exec_op() { 63.216355 | 1) | gpmi_chain_command() { 63.216356 | 1) | mxs_dma_prep_slave_sg() { 63.216357 | 1) | /* mxs chan ccw idx: 0 */ 63.216358 | 1) 1.750 us | } 63.216359 | 1) | mxs_dma_prep_slave_sg() { 63.216360 | 1) | /* mxs chan ccw idx: 1 */ 63.216361 | 1) 2.000 us | } 63.216361 | 1) 6.500 us | } 63.216362 | 1) | gpmi_chain_command() { 63.216363 | 1) | mxs_dma_prep_slave_sg() { 63.216364 | 1) | /* mxs chan ccw idx: 2 */ 63.216365 | 1) 1.750 us | } 63.216366 | 1) | mxs_dma_prep_slave_sg() { 63.216367 | 1) | /* mxs chan ccw idx: 3 */ 63.216367 | 1) 1.750 us | } 63.216368 | 1) 5.875 us | } 63.216369 | 1) | /* gpmi_chain_wait_ready */ 63.216370 | 1) | mxs_dma_prep_slave_sg() { 63.216372 | 1) | /* mxs chan ccw idx: 4 */ 63.216373 | 1) 3.000 us | } 63.216374 | 1) | /* gpmi_chain_data_read */ 63.216376 | 1) | mxs_dma_prep_slave_sg() { 63.216377 | 1) | /* mxs chan ccw idx: 5 */ 63.216378 | 1) 2.000 us | } 63.216379 | 1) 1.125 us | mxs_dma_tx_submit(); 63.216381 | 1) 1.000 us | mxs_dma_enable_chan(); 63.216712 | 0) 2.625 us | mxs_dma_int_handler(); 63.216717 | 0) 4.250 us | bch_irq(); 63.216723 | 0) 1.250 us | mxs_dma_tasklet(); 63.216723 | 1) | /* jiffies left 250 */ 63.216725 | 1) ! 372.000 us | } 63.216726 | 1) 2.625 us | gpmi_count_bitflips(); 63.216730 | 1) ! 379.125 us | } but it's not gurantee that bch irq handled always after dma irq handled, sometimes bch_irq comes first and gpmi_nfc_exec_op won't wait anymore, another gpmi_nfc_exec_op may get invoked before last DMA chain IRQ handled, this messed up the next DMA chain and causes DMA timeout. Check the trace log when issue happened. 63.218923 | 1) | gpmi_ecc_read_page() { 63.218924 | 1) 0.625 us | gpmi_bch_layout_std(); 63.218926 | 1) | gpmi_nfc_exec_op() { 63.218927 | 1) | gpmi_chain_command() { 63.218928 | 1) | mxs_dma_prep_slave_sg() { 63.218929 | 1) | /* mxs chan ccw idx: 0 */ 63.218929 | 1) 1.625 us | } 63.218931 | 1) | mxs_dma_prep_slave_sg() { 63.218931 | 1) | /* mxs chan ccw idx: 1 */ 63.218932 | 1) 1.750 us | } 63.218933 | 1) 5.875 us | } 63.218934 | 1) | gpmi_chain_command() { 63.218934 | 1) | mxs_dma_prep_slave_sg() { 63.218935 | 1) | /* mxs chan ccw idx: 2 */ 63.218936 | 1) 1.875 us | } 63.218937 | 1) | mxs_dma_prep_slave_sg() { 63.218938 | 1) | /* mxs chan ccw idx: 3 */ 63.218939 | 1) 1.625 us | } 63.218939 | 1) 5.875 us | } 63.218940 | 1) | /* gpmi_chain_wait_ready */ 63.218941 | 1) | mxs_dma_prep_slave_sg() { 63.218942 | 1) | /* mxs chan ccw idx: 4 */ 63.218942 | 1) 1.625 us | } 63.218943 | 1) | /* gpmi_chain_data_read */ 63.218944 | 1) | mxs_dma_prep_slave_sg() { 63.218945 | 1) | /* mxs chan ccw idx: 5 */ 63.218947 | 1) 2.375 us | } 63.218948 | 1) 0.625 us | mxs_dma_tx_submit(); 63.218949 | 1) 1.000 us | mxs_dma_enable_chan(); 63.219276 | 0) 5.125 us | bch_irq(); <---- 63.219283 | 1) | /* jiffies left 250 */ 63.219285 | 1) ! 358.625 us | } 63.219286 | 1) 2.750 us | gpmi_count_bitflips(); 63.219289 | 1) ! 366.000 us | } 63.219290 | 1) | gpmi_ecc_read_page() { 63.219291 | 1) 0.750 us | gpmi_bch_layout_std(); 63.219293 | 1) | gpmi_nfc_exec_op() { 63.219294 | 1) | gpmi_chain_command() { 63.219295 | 1) | mxs_dma_prep_slave_sg() { 63.219295 | 0) 1.875 us | mxs_dma_int_handler(); <---- 63.219296 | 1) | /* mxs chan ccw idx: 6 */ 63.219297 | 1) 2.250 us | } 63.219298 | 1) | mxs_dma_prep_slave_sg() { 63.219298 | 0) 1.000 us | mxs_dma_tasklet(); 63.219299 | 1) | /* mxs chan ccw idx: 0 */ 63.219300 | 1) 1.625 us | } 63.219300 | 1) 6.375 us | } 63.219301 | 1) | gpmi_chain_command() { 63.219302 | 1) | mxs_dma_prep_slave_sg() { 63.219303 | 1) | /* mxs chan ccw idx: 1 */ 63.219304 | 1) 1.625 us | } 63.219305 | 1) | mxs_dma_prep_slave_sg() { 63.219306 | 1) | /* mxs chan ccw idx: 2 */ 63.219306 | 1) 1.875 us | } 63.219307 | 1) 6.000 us | } 63.219308 | 1) | /* gpmi_chain_wait_ready */ 63.219308 | 1) | mxs_dma_prep_slave_sg() { 63.219309 | 1) | /* mxs chan ccw idx: 3 */ 63.219310 | 1) 2.000 us | } 63.219311 | 1) | /* gpmi_chain_data_read */ 63.219312 | 1) | mxs_dma_prep_slave_sg() { 63.219313 | 1) | /* mxs chan ccw idx: 4 */ 63.219314 | 1) 1.750 us | } 63.219315 | 1) 0.625 us | mxs_dma_tx_submit(); 63.219316 | 1) 0.875 us | mxs_dma_enable_chan(); 64.224227 | 1) | /* jiffies left 0 */ In the first gpmi_nfc_exec_op, bch_irq comes first and gpmi_nfc_exec_op exits, but DMA IRQ still not happened yet until the middle of following gpmi_nfc_exec_op, the first DMA transfer index get messed and DMA get timeout. To fix the issue, when there is bch ops in DMA chain, the gpmi_nfc_exec_op should wait for both completions rather than bch completion only. Fixes: ef347c0cfd61 ("mtd: rawnand: gpmi: Implement exec_op") Signed-off-by: Han Xu <han.xu@nxp.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201209035104.22679-3-han.xu@nxp.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30mtd: rawnand: meson: Fix a resource leak in initDan Carpenter1-1/+4
[ Upstream commit ad8566d3555c4731e6b48823b92d3929b0394c14 ] Call clk_disable_unprepare(nfc->phase_rx) if the clk_set_rate() function fails to avoid a resource leak. Fixes: 8fae856c5350 ("mtd: rawnand: meson: add support for Amlogic NAND flash controller") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/X8ikVCnUsfTpffFB@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30mtd: rawnand: gpmi: fix reference count leak in gpmi opsZhang Qilong1-2/+6
[ Upstream commit 1b391c7f2e863985668d705f525af3ceb55bc800 ] pm_runtime_get_sync() will increment pm usage at first and it will resume the device later. If runtime of the device has error or device is in inaccessible state(or other error state), resume operation will fail. If we do not call put operation to decrease the reference, it will result in reference leak in the two functions(gpmi_init and gpmi_nfc_exec_op). Moreover, this device cannot enter the idle state and always stay busy or other non-idle state later. So we fixed it through adding pm_runtime_put_noidle. Fixes: 5bc6bb603b4d0 ("mtd: rawnand: gpmi: Fix suspend/resume problem") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Acked-by: Han Xu <han.xu@nxp.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Link: https://lore.kernel.org/linux-mtd/20201107110552.1568742-1-zhangqilong3@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30clk: tegra: Fix duplicated SE clock entryDmitry Osipenko2-1/+2
[ Upstream commit 5bf5861d6ea6c3f4b38fc8fda2062b2dc44ac63d ] The periph_clks[] array contains duplicated entry for Security Engine clock which was meant to be defined for T210, but it wasn't added properly. This patch corrects the T210 SE entry and fixes the following error message on T114/T124: "Tegra clk 127: register failed with -17". Fixes: dc37fec48314 ("clk: tegra: periph: Add new periph clks and muxes for Tegra210") Tested-by Nicolas Chauvet <kwizart@gmail.com> Reported-by Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Link: https://lore.kernel.org/r/20201025224212.7790-1-digetx@gmail.com Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30clk: qcom: gcc-sc7180: Use floor ops for sdcc clksDouglas Anderson1-2/+2
[ Upstream commit 6d37a8d192830267e6b10a6d57ae28d2e89097e7 ] I would repeat the same commit message that was in commit 5e4b7e82d497 ("clk: qcom: gcc-sdm845: Use floor ops for sdcc clks") but it seems silly to do so when you could just go read that commit. NOTE: this is actually extra terrible because we're missing the 50 MHz rate in the table (see the next patch AKA ("clk: qcom: gcc-sc7180: Add 50 MHz clock rate for SDC2")). That means then when you run an older SD card it'll try to clock it at 100 MHz when it's only specced to run at 50 MHz max. As you can probably guess that doesn't work super well. Signed-off-by: Douglas Anderson <dianders@chromium.org> Fixes: 17269568f726 ("clk: qcom: Add Global Clock controller (GCC) driver for SC7180") Link: https://lore.kernel.org/r/20201210102234.1.I096779f219625148900fc984dd0084ed1ba87c7f@changeid Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc/mediatek: unprepare clk if scp_before_load failsTzung-Bi Shih1-1/+2
[ Upstream commit 22c3df6f5574c8d401ea431c7ce24e7c5c5e7ef3 ] Fixes the error handling to unprepare clk if scp_before_load fails. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201203155914.3844426-1-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc: qcom: Fix potential NULL dereference in adsp_init_mmio()Zhang Changzhong1-6/+3
[ Upstream commit c3d4e5b12672bbdf63f4cc933e3169bc6bbec8da ] platform_get_resource() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource() instead of calling platform_get_resource() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: dc160e449122 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607392460-20516-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc: k3-dsp: Fix return value check in k3_dsp_rproc_of_get_memories()YueHaibing1-2/+2
[ Upstream commit 6dfdf6e4e7096fead7755d47d91d72e896bb4804 ] In case of error, the function devm_ioremap_wc() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Fixes: 6edbe024ba17 ("remoteproc: k3-dsp: Add a remoteproc driver of K3 C66x DSPs") Signed-off-by: YueHaibing <yuehaibing@huawei.com> Acked-by: Suman Anna <s-anna@ti.com> Link: https://lore.kernel.org/r/20200905122503.17352-1-yuehaibing@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc: qcom: pas: fix error handling in adsp_pds_enableZhang Qilong1-1/+4
[ Upstream commit c0a6e5ee1ecfe4c3a5799cfd30820748eff5dfab ] If the pm_runtime_get_sync failed in adsp_pds_enable when loop (i), The unroll_pd_votes will start from (i - 1), and it will resulted in following problems: 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak. 2) Have not reset pds[i] performance state. Then we fix it. Fixes: 17ee2fb4e8567 ("remoteproc: qcom: pas: Vote for active/proxy power domains") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143554.144707-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc: qcom: fix reference leak in adsp_startZhang Qilong1-1/+3
[ Upstream commit aa37448f597c09844942da87d042fc6793f989c2 ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak in adsp_start, so we should fix it. Fixes: dc160e4491222 ("remoteproc: qcom: Introduce Non-PAS ADSP PIL driver") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143534.144484-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc: q6v5-mss: fix error handling in q6v5_pds_enableZhang Qilong1-1/+4
[ Upstream commit a24723050037303e4008b37f1f8dcc99c58901aa ] If the pm_runtime_get_sync failed in q6v5_pds_enable when loop (i), The unroll_pd_votes will start from (i - 1), and it will resulted in following problems: 1) pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to pm_runtime_put_noidle will result in reference leak. 2) Have not reset pds[i] performance state. Then we fix it. Fixes: 4760a896be88e ("remoteproc: q6v5-mss: Vote for rpmh power domains") Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201102143433.143996-1-zhangqilong3@huawei.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc/mtk_scp: surround DT device IDs with CONFIG_OFAlexandre Courbot1-0/+2
[ Upstream commit e59aef4edc45133ccb10b8e962cb74dcf1e3240b ] Now that this driver can be compiled with COMPILE_TEST, we have no guarantee that CONFIG_OF will also be defined. When that happens, a warning about mtk_scp_of_match being defined but unused will be reported so make sure this variable is only defined if of_match_ptr() actually uses it. Fixes: cbd2dca74926c0e4610c40923cc786b732c9e8ef remoteproc: scp: add COMPILE_TEST dependency Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Alexandre Courbot <acourbot@chromium.org> Link: https://lore.kernel.org/r/20201102074007.299222-1-acourbot@chromium.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30remoteproc/mediatek: change MT8192 CFG register baseTzung-Bi Shih1-13/+13
[ Upstream commit 0a441514bc2b8a48ebe23c2dcb9feee6351d45b6 ] The correct MT8192 CFG register base is 0x20000 off. Changes the registers accordingly. Fixes: fd0b6c1ff85a ("remoteproc/mediatek: Add support for mt8192 SCP") Signed-off-by: Tzung-Bi Shih <tzungbi@google.com> Link: https://lore.kernel.org/r/20201210054109.587795-1-tzungbi@google.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30RDMA/uverbs: Fix incorrect variable typeAvihai Horon2-9/+15
[ Upstream commit e0da68994d16b46384cce7b86eb645f1ef7c51ef ] Fix incorrect type of max_entries in UVERBS_METHOD_QUERY_GID_TABLE - max_entries is of type size_t although it can take negative values. The following static check revealed it: drivers/infiniband/core/uverbs_std_types_device.c:338 ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE() warn: 'max_entries' unsigned <= 0 Fixes: 9f85cbe50aa0 ("RDMA/uverbs: Expose the new GID query API to user space") Link: https://lore.kernel.org/r/20201208073545.9723-4-leon@kernel.org Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Avihai Horon <avihaih@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30RDMA/core: Do not indicate device ready when device enablement failsJack Morgenstein1-3/+4
[ Upstream commit 779e0bf47632c609c59f527f9711ecd3214dccb0 ] In procedure ib_register_device, procedure kobject_uevent is called (advertising that the device is ready for userspace usage) even when device_enable_and_get() returned an error. As a result, various RDMA modules attempted to register for the device even while the device driver was preparing to unregister the device. Fix this by advertising the device availability only after enabling the device succeeds. Fixes: e7a5b4aafd82 ("RDMA/device: Don't fire uevent before device is fully initialized") Link: https://lore.kernel.org/r/20201208073545.9723-3-leon@kernel.org Suggested-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ALSA: hda/hdmi: fix silent stream for first playback to DPKai Vehmanen1-12/+86
[ Upstream commit b1a5039759cb7bfcb2157f28604dbda0bca58598 ] A problem exists in enabling silent stream when connection type is DisplayPort. Silent stream programming is completed when a new DP receiver is connected, but infoframe transmission does not actually start until PCM is opened for the first time. This can result in audible gap of multiple seconds. This only affects the first PCM open. Fix the issue by properly assigning a converter to the silent stream, and modifying the required stream ID programming sequence. This change only affects Intel display audio codecs. BugLink: https://github.com/thesofproject/linux/issues/2468 Fixes: 951894cf30f4 ("ALSA: hda/hdmi: Add Intel silent stream support") Signed-off-by: Kai Vehmanen <kai.vehmanen@linux.intel.com> Link: https://lore.kernel.org/r/20201210174445.3134104-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()Zhang Changzhong1-7/+2
[ Upstream commit 428bb001143cf5bfb65aa4ae90d4ebc95f82d007 ] platform_get_resource_byname() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource_byname() instead of calling platform_get_resource_byname() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: ad7fcbc308b0 ("slimbus: qcom: Add Qualcomm Slimbus controller driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607392473-20610-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/sstep: Cover new VSX instructions under CONFIG_VSXRavi Bangoria1-1/+3
[ Upstream commit 1817de2f141c718f1a0ae59927ec003e9b144349 ] Recently added Power10 prefixed VSX instruction are included unconditionally in the kernel. If they are executed on a machine without VSX support, it might create issues. Fix that. Also fix one mnemonics spelling mistake in comment. Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores") Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201011050908.72173-3-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/sstep: Emulate prefixed instructions only when CPU_FTR_ARCH_31 is setBalamuruhan S1-0/+6
[ Upstream commit ef6879f8c8053cc3b493f400a06d452d7fb13650 ] Unconditional emulation of prefixed instructions will allow emulation of them on Power10 predecessors which might cause issues. Restrict that. Fixes: 3920742b92f5 ("powerpc sstep: Add support for prefixed fixed-point arithmetic") Fixes: 50b80a12e4cc ("powerpc sstep: Add support for prefixed load/stores") Signed-off-by: Balamuruhan S <bala24@linux.ibm.com> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com> Reviewed-by: Sandipan Das <sandipan@linux.ibm.com> Reviewed-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201011050908.72173-2-ravi.bangoria@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30can: m_can: m_can_config_endisable(): remove double clearing of clock stop ↵Sean Nyekjaer1-4/+0
request bit [ Upstream commit c9f4cad6cdfe350ce2637e57f7f2aa7ff326bcc6 ] The CSR bit is already cleared when arriving here so remove this section of duplicate code. The registers set in m_can_config_endisable() is set to same exact values as before this patch. Signed-off-by: Sean Nyekjaer <sean@geanix.com> Acked-by: Sriram Dash <sriram.dash@samsung.com> Acked-by: Dan Murphy <dmurphy@ti.com> Link: https://lore.kernel.org/r/20191211063227.84259-1-sean@geanix.com Fixes: f524f829b75a ("can: m_can: Create a m_can platform framework") Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30clk: renesas: r8a779a0: Fix R and OSC clocksGeert Uytterhoeven1-3/+10
[ Upstream commit 14653942de7f63e21ece32e3901f09a248598a43 ] The R-Car V3U clock driver defines the R and OSC clocks using R-Car Gen3 clock types. However, The R-Car V3U clock driver does not use the R-Car Gen3 clock driver core, hence registering the R and OSC clocks fails: renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock osc: -22 renesas-cpg-mssr e6150000.clock-controller: Failed to register core clock r: -22 Fix this by introducing clock definition macros specific to R-Car V3U. Note that rcar_r8a779a0_cpg_clk_register() already handled the related clock types. Drop the now unneeded include of rcar-gen3-cpg.h. Fixes: 17bcc8035d2d19fc ("clk: renesas: cpg-mssr: Add support for R-Car V3U") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20201109152614.2465483-1-geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30erofs: avoid using generic_block_bmapHuang Jianan1-19/+7
[ Upstream commit d8b3df8b1048405e73558b88cba2adf29490d468 ] Surprisingly, `block' in sector_t indicates the number of i_blkbits-sized blocks rather than sectors for bmap. In addition, considering buffer_head limits mapped size to 32-bits, should avoid using generic_block_bmap. Link: https://lore.kernel.org/r/20201209115740.18802-1-huangjianan@oppo.com Fixes: 9da681e017a3 ("staging: erofs: support bmap") Reviewed-by: Chao Yu <yuchao0@huawei.com> Reviewed-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Huang Jianan <huangjianan@oppo.com> Signed-off-by: Guo Weichao <guoweichao@oppo.com> [ Gao Xiang: slightly update the commit message description. ] Signed-off-by: Gao Xiang <hsiangkao@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30iwlwifi: mvm: hook up missing RX handlersJohannes Berg1-0/+6
[ Upstream commit 8a59d39033c35bb484f6bd91891db86ebe07fdc2 ] The RX handlers for probe response data and channel switch weren't hooked up properly, fix that. Fixes: 86e177d80ff7 ("iwlwifi: mvm: add NOA and CSA to a probe response") Fixes: d3a108a48dc6 ("iwlwifi: mvm: Support CSA countdown offloading") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.2d07dcee0d35.I07a61b5d734478db57d9434ff303e4c90bf6c32b@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30iwlwifi: dbg-tlv: fix old length in is_trig_data_contained()Johannes Berg1-1/+1
[ Upstream commit 58a1c9f9a9b6b9092ae10b84f6b571a06596e296 ] There's a bug in the lengths - the 'old length' needs to be calculated using the 'old' pointer, of course, likely a copy/paste mistake. Fix this. Reported-by: Daniel Gabay <daniel.gabay@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Fixes: cf29c5b66b9f ("iwlwifi: dbg_ini: implement time point handling") Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201209231352.c0105ddffa74.I1ddb243053ff763c91b663748b6a593ecc3b5634@changeid Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30s390/cio: fix use-after-free in ccw_device_destroy_consoleQinglang Miao1-2/+2
[ Upstream commit 14d4c4fa46eeaa3922e8e1c4aa727eb0a1412804 ] Use of sch->dev reference after the put_device() call could trigger the use-after-free bugs. Fix this by simply adjusting the position of put_device. Fixes: 37db8985b211 ("s390/cio: add basic protected virtualization support") Reported-by: Hulk Robot <hulkci@huawei.com> Suggested-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com> [vneethv@linux.ibm.com: Slight modification in the commit-message] Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30fsi: Aspeed: Add mutex to protect HW accessEddie James1-16/+29
[ Upstream commit dfd7f2c1c532efaeff6084970bb60ec2f2e44191 ] There is nothing to prevent multiple commands being executed simultaneously. Add a mutex to prevent this. Fixes: 606397d67f41 ("fsi: Add ast2600 master driver") Reviewed-by: Joel Stanley <joel@jms.id.au> Reviewed-by: Milton Miller <miltonm@us.ibm.com> Signed-off-by: Eddie James <eajames@linux.ibm.com> Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://lore.kernel.org/r/20201120004929.185239-1-joel@jms.id.au Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30bus: fsl-mc: fix error return code in fsl_mc_object_allocate()Zhang Changzhong1-1/+3
[ Upstream commit 3d70fb03711c37bc64e8e9aea5830f498835f6bf ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 197f4d6a4a00 ("staging: fsl-mc: fsl-mc object allocator driver") Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607068967-31991-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30bus: fsl-mc: add back accidentally dropped error checkLaurentiu Tudor1-1/+4
[ Upstream commit 61243c03dde238170001093a29716c2369e8358f ] A previous patch accidentally dropped an error check, so add it back. Fixes: aef85b56c3c1 ("bus: fsl-mc: MC control registers are not always available") Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Link: https://lore.kernel.org/r/20201105153050.19662-1-laurentiu.tudor@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30misc: pci_endpoint_test: fix return value of error branchXiongfeng Wang1-2/+6
[ Upstream commit 1749c90489f2afa6b59dbf3ab59d58a9014c84a1 ] We return 'err' in the error branch, but this variable may be set as zero before. Fix it by setting 'err' as a negative value before we goto the error label. Fixes: e03327122e2c ("pci_endpoint_test: Add 2 ioctl commands") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Link: https://lore.kernel.org/r/1605790158-6780-1-git-send-email-wangxiongfeng2@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30platform/chrome: cros_ec_spi: Don't overwrite spi::modeStephen Boyd1-1/+0
[ Upstream commit 74639cbf51d7c0304342544a83dfda354a6bd208 ] There isn't any need to overwrite the mode here in the driver with what has been detected by the firmware, such as DT or ACPI. In fact, if we use the SPI CS gpio descriptor feature we will overwrite the mode with SPI_MODE_0 where it already contains SPI_MODE_0 and more importantly SPI_CS_HIGH. Clearing the SPI_CS_HIGH bit causes the CS line to toggle when the device is probed when it shouldn't change, confusing the driver and making it fail to probe. Drop the assignment and let the spi core take care of it. Fixes: a17d94f0b6e1 ("mfd: Add ChromeOS EC SPI driver") Cc: Simon Glass <sjg@chromium.org> Cc: Gwendal Grignou <gwendal@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Acked-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Cc: Alexandru M Stan <amstan@chromium.org> Signed-off-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Link: https://lore.kernel.org/r/20201204193540.3047030-2-swboyd@chromium.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30scsi: qla2xxx: Fix N2N and NVMe connect retry failureQuinn Tran2-22/+52
[ Upstream commit 07a5f69248e3486e387c40af64793466371c7d91 ] FC-NVMe target discovery failed when initiator wwpn < target wwpn in an N2N (Direct Attach) config, where the driver was stuck on FCP PRLI mode and failed to retry with NVMe PRLI. Link: https://lore.kernel.org/r/20201202132312.19966-10-njavali@marvell.com Fixes: 84ed362ac40c ("scsi: qla2xxx: Dual FCP-NVMe target port support”) Fixes: 983f127603fa ("scsi: qla2xxx: Retry PLOGI on FC-NVMe PRLI failure”) Signed-off-by: Quinn Tran <qutran@marvell.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30scsi: qla2xxx: Fix FW initialization error on big endian machinesArun Easi1-3/+3
[ Upstream commit 8a78dd6ed1af06bfa7b4ade81328ff7ea11b6947 ] Some fields are not correctly byte swapped causing failure during initialization. As probe() returns failure, HBAs will not be claimed when this happens. qla2xxx [0007:01:00.0]-ffff:3: Secure Flash Update in FW: Supported qla2xxx [0007:01:00.0]-ffff:3: SCM in FW: Supported qla2xxx [0007:01:00.0]-00d2:3: Init Firmware **** FAILED ****. qla2xxx [0007:01:00.0]-00d6:3: Failed to initialize adapter - Adapter flags 2. qla2xxx 0007:01:00.1: enabling device (0140 -> 0142) qla2xxx [0007:01:00.1]-011c: : MSI-X vector count: 128. qla2xxx [0007:01:00.1]-001d: : Found an ISP2289 irq 18 iobase 0xd000080080004000. qla2xxx 0007:01:00.1: Using 64-bit direct DMA at offset 800000000000000 BUG: Bad page state in process insmod pfn:67118 page:f00000000168bd40 count:-1 mapcount:0 mapping: (null) index:0x0 page flags: 0x3ffff800000000() page dumped because: nonzero _count Modules linked in: qla2xxx(OE+) nvme_fc nvme_fabrics nvme_core scsi_transport_fc scsi_tgt nls_utf8 isofs ip6t_rpfilter ipt_REJECT nf_reject_ipv4 ip6t_REJECT nf_reject_ipv6 xt_conntrack ip_set nfnetlink ebtable_nat ebtable_broute bridge stp llc ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter nx_crypto ses enclosure scsi_transport_sas pseries_rng sg ip_tables xfs libcrc32c sr_mod cdrom sd_mod crc_t10dif crct10dif_generic crct10dif_common usb_storage ipr libata tg3 ptp pps_core dm_mirror dm_region_hash dm_log dm_mod CPU: 32 PID: 8560 Comm: insmod Kdump: loaded Tainted: G OE ------------ 3.10.0-957.el7.ppc64 #1 Call Trace: [c0000006dd7caa70] [c00000000001cca8] .show_stack+0x88/0x330 (unreliable) [c0000006dd7cab30] [c000000000ac3d88] .dump_stack+0x28/0x3c [c0000006dd7caba0] [c00000000029e48c] .bad_page+0x15c/0x1c0 [c0000006dd7cac40] [c00000000029f938] .get_page_from_freelist+0x11e8/0x1ea0 [c0000006dd7caf40] [c0000000002a1d30] .__alloc_pages_nodemask+0x1c0/0xc70 [c0000006dd7cb140] [c00000000002ba0c] .__dma_direct_alloc_coherent+0x8c/0x170 [c0000006dd7cb1e0] [d000000010a94688] .qla2x00_mem_alloc+0x10f8/0x1370 [qla2xxx] [c0000006dd7cb2d0] [d000000010a9c790] .qla2x00_probe_one+0xb60/0x22e0 [qla2xxx] [c0000006dd7cb540] [c0000000005de764] .pci_device_probe+0x204/0x300 [c0000006dd7cb600] [c0000000006ca61c] .driver_probe_device+0x2cc/0x6f0 [c0000006dd7cb6b0] [c0000000006cabec] .__driver_attach+0x10c/0x110 [c0000006dd7cb740] [c0000000006c5f04] .bus_for_each_dev+0x94/0x100 [c0000006dd7cb7e0] [c0000000006c94f4] .driver_attach+0x34/0x50 [c0000006dd7cb860] [c0000000006c8f58] .bus_add_driver+0x298/0x3b0 [c0000006dd7cb900] [c0000000006cb6e0] .driver_register+0xb0/0x1a0 [c0000006dd7cb980] [c0000000005dc474] .__pci_register_driver+0xc4/0xf0 [c0000006dd7cba10] [d000000010b94e20] .qla2x00_module_init+0x2a8/0x328 [qla2xxx] [c0000006dd7cbaa0] [c00000000000c130] .do_one_initcall+0x130/0x2e0 [c0000006dd7cbb50] [c0000000001b2e8c] .load_module+0x1afc/0x2340 [c0000006dd7cbd40] [c0000000001b3920] .SyS_finit_module+0xd0/0x130 [c0000006dd7cbe30] [c00000000000a284] system_call+0x38/0xfc Link: https://lore.kernel.org/r/20201202132312.19966-9-njavali@marvell.com Fixes: 9f2475fe7406 ("scsi: qla2xxx: SAN congestion management implementation") Fixes: cf3c54fb49a4 ("scsi: qla2xxx: Add SLER and PI control support”) Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com> Signed-off-by: Arun Easi <aeasi@marvell.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30x86/kprobes: Restore BTF if the single-stepping is cancelledMasami Hiramatsu1-0/+5
[ Upstream commit 78ff2733ff352175eb7f4418a34654346e1b6cd2 ] Fix to restore BTF if single-stepping causes a page fault and it is cancelled. Usually the BTF flag was restored when the single stepping is done (in resume_execution()). However, if a page fault happens on the single stepping instruction, the fault handler is invoked and the single stepping is cancelled. Thus, the BTF flag is not restored. Fixes: 1ecc798c6764 ("x86: debugctlmsr kprobes") Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/160389546985.106936.12727996109376240993.stgit@devnote2 Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30nfs_common: need lock during iterate through the listCheng Lin1-1/+5
[ Upstream commit 4a9d81caf841cd2c0ae36abec9c2963bf21d0284 ] If the elem is deleted during be iterated on it, the iteration process will fall into an endless loop. kernel: NMI watchdog: BUG: soft lockup - CPU#4 stuck for 22s! [nfsd:17137] PID: 17137  TASK: ffff8818d93c0000  CPU: 4   COMMAND: "nfsd"     [exception RIP: __state_in_grace+76]     RIP: ffffffffc00e817c  RSP: ffff8818d3aefc98  RFLAGS: 00000246     RAX: ffff881dc0c38298  RBX: ffffffff81b03580  RCX: ffff881dc02c9f50     RDX: ffff881e3fce8500  RSI: 0000000000000001  RDI: ffffffff81b03580     RBP: ffff8818d3aefca0   R8: 0000000000000020   R9: ffff8818d3aefd40     R10: ffff88017fc03800  R11: ffff8818e83933c0  R12: ffff8818d3aefd40     R13: 0000000000000000  R14: ffff8818e8391068  R15: ffff8818fa6e4000     CS: 0010  SS: 0018  #0 [ffff8818d3aefc98] opens_in_grace at ffffffffc00e81e3 [grace]  #1 [ffff8818d3aefca8] nfs4_preprocess_stateid_op at ffffffffc02a3e6c [nfsd]  #2 [ffff8818d3aefd18] nfsd4_write at ffffffffc028ed5b [nfsd]  #3 [ffff8818d3aefd80] nfsd4_proc_compound at ffffffffc0290a0d [nfsd]  #4 [ffff8818d3aefdd0] nfsd_dispatch at ffffffffc027b800 [nfsd]  #5 [ffff8818d3aefe08] svc_process_common at ffffffffc02017f3 [sunrpc]  #6 [ffff8818d3aefe70] svc_process at ffffffffc0201ce3 [sunrpc]  #7 [ffff8818d3aefe98] nfsd at ffffffffc027b117 [nfsd]  #8 [ffff8818d3aefec8] kthread at ffffffff810b88c1  #9 [ffff8818d3aeff50] ret_from_fork at ffffffff816d1607 The troublemake elem: crash> lock_manager ffff881dc0c38298 struct lock_manager {   list = {     next = 0xffff881dc0c38298,     prev = 0xffff881dc0c38298   },   block_opens = false } Fixes: c87fb4a378f9 ("lockd: NLM grace period shouldn't block NFSv4 opens") Signed-off-by: Cheng Lin <cheng.lin130@zte.com.cn> Signed-off-by: Yi Wang <wang.yi59@zte.com.cn> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30NFSD: Fix 5 seconds delay when doing inter server copyDai Ngo1-0/+1
[ Upstream commit ca9364dde50daba93eff711b4b945fd08beafcc2 ] Since commit b4868b44c5628 ("NFSv4: Wait for stateid updates after CLOSE/OPEN_DOWNGRADE"), every inter server copy operation suffers 5 seconds delay regardless of the size of the copy. The delay is from nfs_set_open_stateid_locked when the check by nfs_stateid_is_sequential fails because the seqid in both nfs4_state and nfs4_stateid are 0. Fix by modifying nfs4_init_cp_state to return the stateid with seqid 1 instead of 0. This is also to conform with section 4.8 of RFC 7862. Here is the relevant paragraph from section 4.8 of RFC 7862: A copy offload stateid's seqid MUST NOT be zero. In the context of a copy offload operation, it is inappropriate to indicate "the most recent copy offload operation" using a stateid with a seqid of zero (see Section 8.2.2 of [RFC5661]). It is inappropriate because the stateid refers to internal state in the server and there may be several asynchronous COPY operations being performed in parallel on the same file by the server. Therefore, a copy offload stateid with a seqid of zero MUST be considered invalid. Fixes: ce0887ac96d3 ("NFSD add nfs4 inter ssc to nfsd4_copy") Signed-off-by: Dai Ngo <dai.ngo@oracle.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30nfsd: Fix message level for normal terminationkazuo ito1-2/+1
[ Upstream commit 4420440c57892779f265108f46f83832a88ca795 ] The warning message from nfsd terminating normally can confuse system adminstrators or monitoring software. Though it's not exactly fair to pin-point a commit where it originated, the current form in the current place started to appear in: Fixes: e096bbc6488d ("knfsd: remove special handling for SIGHUP") Signed-off-by: kazuo ito <kzpn200@gmail.com> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30speakup: fix uninitialized flush_lockYang Yingliang1-1/+1
[ Upstream commit d1b928ee1cfa965a3327bbaa59bfa005d97fa0fe ] The flush_lock is uninitialized, use DEFINE_SPINLOCK to define and initialize flush_lock. Fixes: c6e3fd22cd53 ("Staging: add speakup to the staging directory") Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20201117012229.3395186-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30usb: oxu210hp-hcd: Fix memory leak in oxu_createZhang Qilong1-1/+3
[ Upstream commit e5548b05631ec3e6bfdaef1cad28c799545b791b ] usb_create_hcd will alloc memory for hcd, and we should call usb_put_hcd to free it when adding fails to prevent memory leak. Fixes: b92a78e582b1a ("usb host: Oxford OXU210HP HCD driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201123145809.1456541-1-zhangqilong3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30usb: ehci-omap: Fix PM disable depth umbalance in ehci_hcd_omap_probeZhang Qilong1-0/+1
[ Upstream commit d6ff32478d7e95d6ca199b5c852710d6964d5811 ] The pm_runtime_enable will decrement the power disable depth. Imbalance depth will resulted in enabling runtime PM of device fails later. Thus a pairing decrement must be needed on the error handling path to keep it balanced. Fixes: 6c984b066d84b ("ARM: OMAP: USBHOST: Replace usbhs core driver APIs by Runtime pm APIs") Acked-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com> Link: https://lore.kernel.org/r/20201123145719.1455849-1-zhangqilong3@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/mm: sanity_check_fault() should work for all, not only BOOK3SChristophe Leroy1-5/+3
[ Upstream commit 7ceb40027e19567a0a066e3b380cc034cdd9a124 ] The verification and message introduced by commit 374f3f5979f9 ("powerpc/mm/hash: Handle user access of kernel address gracefully") applies to all platforms, it should not be limited to BOOK3S. Make the BOOK3S version of sanity_check_fault() the one for all, and bail out earlier if not BOOK3S. Fixes: 374f3f5979f9 ("powerpc/mm/hash: Handle user access of kernel address gracefully") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/fe199d5af3578d3bf80035d203a94d742a7a28af.1607491748.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ASoC: max98390: Fix error codes in max98390_dsm_init()Dan Carpenter1-0/+2
[ Upstream commit 3cea33b6f2d7782d1be17c71509986f33ee93541 ] These error paths return success but they should return -EINVAL. Fixes: 97ed3e509ee6 ("ASoC: max98390: Fix potential crash during param fw loading") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/X9B0uz4svyNTqeMb@mwanda Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30coresight: remove broken __exit annotationsArnd Bergmann10-16/+16
[ Upstream commit 45fe7befe0db5e61cd3c846315f0ac48541e8445 ] Functions that are annotated __exit are discarded for built-in drivers, but the .remove callback in a device driver must still be kept around to allow bind/unbind operations. There is now a linker warning for the discarded symbol references: `tmc_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tmc-core.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tmc-core.o `tpiu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-tpiu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-tpiu.o `etb_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-etb10.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-etb10.o `static_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o `dynamic_funnel_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-funnel.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-funnel.o `static_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o `dynamic_replicator_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-replicator.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-replicator.o `catu_remove' referenced in section `.data' of drivers/hwtracing/coresight/coresight-catu.o: defined in discarded section `.exit.text' of drivers/hwtracing/coresight/coresight-catu.o Remove all those annotations. Fixes: 8b0cf82677d1 ("coresight: stm: Allow to build coresight-stm as a module") Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208182651.1597945-3-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ASoC: amd: change clk_get() to devm_clk_get() and add missed checksChuhong Yuan1-2/+7
[ Upstream commit 95d3befbc5e1ee39fc8a78713924cf7ed2b3cabe ] cz_da7219_init() does not check the return values of clk_get(), while da7219_clk_enable() calls clk_set_rate() to dereference the pointers. Add checks to fix the problems. Also, change clk_get() to devm_clk_get() to avoid data leak after failures. Fixes: bb24a31ed584 ("ASoC: AMD: Configure wclk and bclk of master codec") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Link: https://lore.kernel.org/r/20201204063610.513556-1-hslester96@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/mediatek: avoid dereferencing a null hdmi_phy on an error messageColin Ian King1-2/+3
[ Upstream commit b097efba9580d1f7cbc80cda84e768983e3de541 ] Currently there is a null pointer check for hdmi_phy that implies it may be null, however a dev_err messages dereferences this potential null pointer. Avoid a null pointer dereference by only emitting the dev_err message if hdmi_phy is non-null. It is a moot point if the error message needs to be printed at all, but since this is a relatively new piece of code it may be useful to keep the message in for the moment in case there are unforseen errors that need to be reported. Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file") Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Dereference after null check") Link: https://lore.kernel.org/r/20201207150937.170435-1-colin.king@canonical.com [vkoul: fix indent of return call] Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/powermac: Fix low_sleep_handler with CONFIG_VMAP_STACKChristophe Leroy2-74/+60
[ Upstream commit db972a3787d12b1ce9ba7a31ec376d8a79e04c47 ] low_sleep_handler() can't restore the context from standard stack because the stack can hardly be accessed with MMU OFF. Store everything in a global storage area instead of storing a pointer to the stack in that global storage area. To avoid a complete churn of the function, still use r1 as the pointer to the storage area during restore. Fixes: cd08f109e262 ("powerpc/32s: Enable CONFIG_VMAP_STACK") Reported-by: Giuseppe Sacco <giuseppe@sguazz.it> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Tested-by: Giuseppe Sacco <giuseppe@sguazz.it> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/e3e0d8042a3ba75cb4a9546c19c408b5b5b28994.1607404931.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/pseries/hibernation: remove redundant cacheinfo updateNathan Lynch1-3/+0
[ Upstream commit b866459489fe8ef0e92cde3cbd6bbb1af6c4e99b ] Partitions with cache nodes in the device tree can encounter the following warning on resume: CPU 0 already accounted in PowerPC,POWER9@0(Data) WARNING: CPU: 0 PID: 3177 at arch/powerpc/kernel/cacheinfo.c:197 cacheinfo_cpu_online+0x640/0x820 These calls to cacheinfo_cpu_offline/online have been redundant since commit e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration"). Fixes: e610a466d16a ("powerpc/pseries/mobility: rebuild cacheinfo hierarchy post-migration") Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201207215200.1785968-25-nathanl@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30powerpc/pseries/hibernation: drop pseries_suspend_begin() from suspend opsNathan Lynch1-1/+0
[ Upstream commit 52719fce3f4c7a8ac9eaa191e8d75a697f9fbcbc ] There are three ways pseries_suspend_begin() can be reached: 1. When "mem" is written to /sys/power/state: kobj_attr_store() -> state_store() -> pm_suspend() -> suspend_devices_and_enter() -> pseries_suspend_begin() This never works because there is no way to supply a valid stream id using this interface, and H_VASI_STATE is called with a stream id of zero. So this call path is useless at best. 2. When a stream id is written to /sys/devices/system/power/hibernate. pseries_suspend_begin() is polled directly from store_hibernate() until the stream is in the "Suspending" state (i.e. the platform is ready for the OS to suspend execution): dev_attr_store() -> store_hibernate() -> pseries_suspend_begin() 3. When a stream id is written to /sys/devices/system/power/hibernate (continued). After #2, pseries_suspend_begin() is called once again from the pm core: dev_attr_store() -> store_hibernate() -> pm_suspend() -> suspend_devices_and_enter() -> pseries_suspend_begin() This is redundant because the VASI suspend state is already known to be Suspending. The begin() callback of platform_suspend_ops is optional, so we can simply remove that assignment with no loss of function. Fixes: 32d8ad4e621d ("powerpc/pseries: Partition hibernation support") Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20201207215200.1785968-18-nathanl@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30ARM: 9030/1: entry: omit FP emulation for UND exceptions taken in kernel modeArd Biesheuvel3-30/+49
[ Upstream commit f77ac2e378be9dd61eb88728f0840642f045d9d1 ] There are a couple of problems with the exception entry code that deals with FP exceptions (which are reported as UND exceptions) when building the kernel in Thumb2 mode: - the conditional branch to vfp_kmode_exception in vfp_support_entry() may be out of range for its target, depending on how the linker decides to arrange the sections; - when the UND exception is taken in kernel mode, the emulation handling logic is entered via the 'call_fpe' label, which means we end up using the wrong value/mask pairs to match and detect the NEON opcodes. Since UND exceptions in kernel mode are unlikely to occur on a hot path (as opposed to the user mode version which is invoked for VFP support code and lazy restore), we can use the existing undef hook machinery for any kernel mode instruction emulation that is needed, including calling the existing vfp_kmode_exception() routine for unexpected cases. So drop the call to call_fpe, and instead, install an undef hook that will get called for NEON and VFP instructions that trigger an UND exception in kernel mode. While at it, make sure that the PC correction is accurate for the execution mode where the exception was taken, by checking the PSR Thumb bit. Cc: Dmitry Osipenko <digetx@gmail.com> Cc: Kees Cook <keescook@chromium.org> Fixes: eff8728fe698 ("vmlinux.lds.h: Add PGO and AutoFDO input sections") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-17 21:21:27 +0300