summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-06-24firmware: qcom_scm: fix bogous abuse of dma-direct internalsChristoph Hellwig1-6/+3
[ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ] As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24pinctrl: rza1: Fix wrong array assignment of rza1l_swio_entriesJason Yan1-1/+1
[ Upstream commit 4b4e8e93eccc2abc4209fe226ec89e7fbe9f3c61 ] The rza1l_swio_entries referred to the wrong array rza1h_swio_pins, which was intended to be rza1l_swio_pins. So let's fix it. This is detected by the following gcc warning: drivers/pinctrl/pinctrl-rza1.c:401:35: warning: ‘rza1l_swio_pins’ defined but not used [-Wunused-const-variable=] static const struct rza1_swio_pin rza1l_swio_pins[] = { ^~~~~~~~~~~~~~~ Fixes: 039bc58e73b77723 ("pinctrl: rza1: Add support for RZ/A1L") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jason Yan <yanaijie@huawei.com> Link: https://lore.kernel.org/r/20200417111604.19143-1-yanaijie@huawei.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24iio: buffer-dmaengine: use %zu specifier for sprintf(align)Alexandru Ardelean1-1/+1
[ Upstream commit 6eb3b8acfd079104571c207d4524743b6acc6550 ] The 'size_t' type behaves differently on 64-bit architectures, and causes compiler a warning of the sort "format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}'". This change adds the correct specifier for the 'align' field. Fixes: 4538c18568099 ("iio: buffer-dmaengine: Report buffer length requirements") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: qedf: Fix crash when MFW calls for protocol stats while function is ↵Chad Dupuis2-4/+32
still probing [ Upstream commit ad40f5256095c68dc17c991eb976261d5ea2daaa ] The MFW may make a call to qed and then to qedf for protocol statistics while the function is still probing. If this happens it's possible that some members of the struct qedf_ctx may not be fully initialized which can result in a NULL pointer dereference or general protection fault. To prevent this, add a new flag call QEDF_PROBING and set it when the __qedf_probe() function is active. Then in the qedf_get_protocol_tlv_data() function we can check if the function is still probing and return immediantely before any uninitialized structures can be touched. Link: https://lore.kernel.org/r/20200416084314.18851-9-skashyap@marvell.com Signed-off-by: Chad Dupuis <cdupuis@marvell.com> Signed-off-by: Saurav Kashyap <skashyap@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24gpio: dwapb: Append MODULE_ALIAS for platform driverAndy Shevchenko1-3/+6
[ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ] The commit 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") introduced a use of the platform driver but missed to add the following line to it: MODULE_ALIAS("platform:gpio-dwapb"); Add this to get driver loaded automatically if platform device is registered. Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Reviewed-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24RDMA/mlx5: Fix udata response upon SRQ creationYishai Hadas1-2/+8
[ Upstream commit cf26deff9036cd3270af562dbec545239e5c7f07 ] Fix udata response upon SRQ creation to use the UAPI structure (i.e. mlx5_ib_create_srq_resp). It did not zero the reserved field in userspace. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20200406173540.1466477-1-leon@kernel.org Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: qedi: Do not flush offload work if ARP not resolvedNilesh Javali1-1/+2
[ Upstream commit 927527aea0e2a9c1d336c7d33f77f1911481d008 ] For an unreachable target, offload_work is not initialized and the endpoint state is set to OFLDCONN_NONE. This results in a WARN_ON due to the check of the work function field being set to zero. ------------[ cut here ]------------ WARNING: CPU: 24 PID: 18587 at ../kernel/workqueue.c:3037 __flush_work+0x1c1/0x1d0 : Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 02/01/2020 RIP: 0010:__flush_work+0x1c1/0x1d0 Code: ba 6d 00 03 80 c9 f0 eb b6 48 c7 c7 20 ee 6c a4 e8 52 d3 04 00 0f 0b 31 c0 e9 d1 fe ff ff 48 c7 c7 20 ee 6c a4 e8 3d d3 04 00 <0f> 0b 31 c0 e9 bc fe ff ff e8 11 f3 f 00 31 f6 RSP: 0018:ffffac5a8cd47a80 EFLAGS: 00010282 RAX: 0000000000000024 RBX: ffff98d68c1fcaf0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff98ce9fd99898 RDI: ffff98ce9fd99898 RBP: ffff98d68c1fcbc0 R08: 00000000000006fa R09: 0000000000000001 R10: ffffac5a8cd47b50 R11: 0000000000000001 R12: 0000000000000000 R13: 000000000000489b R14: ffff98d68c1fc800 R15: ffff98d692132c00 FS: 00007f65f7f62280(0000) GS:ffff98ce9fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd2435e880 CR3: 0000000809334003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? class_create_release+0x40/0x40 ? klist_put+0x2c/0x80 qedi_ep_disconnect+0xdd/0x400 [qedi] iscsi_if_ep_disconnect.isra.20+0x59/0x70 [scsi_transport_iscsi] iscsi_if_rx+0x129b/0x1670 [scsi_transport_iscsi] ? __netlink_lookup+0xe7/0x160 netlink_unicast+0x21d/0x300 netlink_sendmsg+0x30f/0x430 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1e2/0x240 ? copy_msghdr_from_user+0xd9/0x160 ___sys_sendmsg+0x88/0xd0 ? ___sys_recvmsg+0xa2/0xe0 ? hrtimer_try_to_cancel+0x25/0x100 ? do_nanosleep+0x9c/0x170 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f65f6f16107 Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 aa d2 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 8 0 00 00 00 00 53 48 89 f3 48 RSP: 002b:00007ffd24367ca8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a7aeaaf110 RCX: 00007f65f6f16107 RDX: 0000000000000000 RSI: 00007ffd24367cc0 RDI: 0000000000000003 RBP: 0000000000000070 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000075c R11: 0000000000000246 R12: 00007ffd24367cc0 R13: 000055a7ae560008 R14: 00007ffd24367db0 R15: 0000000000000000 ---[ end trace 54f499c05d41f8bb ]--- Only flush if the connection endpoint state if different from OFLDCONN_NONE. [mkp: clarified commit desc] Link: https://lore.kernel.org/r/20200408064332.19377-5-mrangankar@marvell.com Reviewed-by: Lee Duncan <lduncan@suse.com> Signed-off-by: Nilesh Javali <njavali@marvell.com> Signed-off-by: Manish Rangankar <mrangankar@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24staging: mt7621-pci: fix PCIe interrupt mappingSergio Paracuellos2-7/+38
[ Upstream commit fab6710e4c51f4eb622f95a08322ab5fdbe3f295 ] MT7621 has three assigned interrupts for the pcie. This interrupts should properly being mapped taking into account which devices are finally connected in which bus according to link status. So the irq mappings should be as follows according to link status (three bits indicating which devices are link up): * For PCIe Bus 1 slot 0: - status = 0x2 || status = 0x6 => IRQ = pcie1_irq (24). - status = 0x4 => IRQ = pcie2_irq (25). - default => IRQ = pcie0_irq (23). * For PCIe Bus 2 slot 0: - status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25). - default => IRQ = pcie1_irq (24). * For PCIe Bus 2 slot 1: - status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25). - default => IRQ = pcie1_irq (24). * For PCIe Bus 3 any slot: - default => IRQ = pcie2_irq (25). Because of this, the function 'of_irq_parse_and_map_pci' cannot be used and we need to change device tree information from using the 'interrupt-map' and 'interrupt-map-mask' properties into an 'interrupts' property to be able to get irq information from the ports using the 'platform_get_irq' and storing an 'irq-map' into the pcie driver data node to properly map correct irq using a new 'mt7621_map_irq' function where this map will be read and the correct irq returned. Fixes: 46d093124df4 ("staging: mt7621-pci: improve interrupt mapping") Signed-off-by: Sergio Paracuellos <sergio.paracuellos@gmail.com> Link: https://lore.kernel.org/r/20200413055942.2714-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24staging: greybus: fix a missing-check bug in gb_lights_light_config()Chen Zhou1-1/+2
[ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou <chenzhou10@huawei.com> Acked-by: Rui Miguel Silva <rmfrfs@gmail.com> Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24ibmvnic: Flush existing work items before device removalThomas Falcon1-0/+3
[ Upstream commit 6954a9e4192b86d778fb52b525fd7b62d51b1147 ] Ensure that all scheduled work items have completed before continuing with device removal and after further event scheduling has been halted. This patch fixes a bug where a scheduled driver reset event is processed following device removal. Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24media: v4l2-ctrls: Unset correct HEVC loop filter flagJonas Karlman1-1/+1
[ Upstream commit 88441917dc6cd995cb993df603e264f5b88be50c ] Wrong loop filter flag is unset when tiles enabled flag is not set, this cause HEVC decoding issues with Rockchip Video Decoder. Fix this by unsetting the loop filter across tiles enabled flag instead of the pps loop filter across slices enabled flag when tiles are disabled. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24media: s5p-mfc: Properly handle dma_parms for the allocated devicesMarek Szyprowski1-1/+5
[ Upstream commit cc8c0363ddce6308168d8223378ca884c213f280 ] Commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 added allocation of dma_parms structure to all platform devices. Then vb2_dma_contig_set_max_seg_size() have been changed not to allocate dma_parms structure and rely on the one allocated by the device core. Lets allocate the needed structure also for the devices created for the 2 MFC device memory ports. Reported-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Suggested-by: Ulf Hansson <ulf.hansson@linaro.org> Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: ibmvscsi: Don't send host info in adapter info MAD after LPMTyrel Datwyler1-0/+2
[ Upstream commit 4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ] The adapter info MAD is used to send the client info and receive the host info as a response. A persistent buffer is used and as such the client info is overwritten after the response. During the course of a normal adapter reset the client info is refreshed in the buffer in preparation for sending the adapter info MAD. However, in the special case of LPM where we reenable the CRQ instead of a full CRQ teardown and reset we fail to refresh the client info in the adapter info buffer. As a result, after Live Partition Migration (LPM) we erroneously report the host's info as our own. [mkp: typos] Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler <tyreld@linux.ibm.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: sr: Fix sr_probe() missing deallocate of device minorSimon Arlott1-1/+5
[ Upstream commit 6555781b3fdec5e94e6914511496144241df7dee ] If the cdrom fails to be registered then the device minor should be deallocated. Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe Signed-off-by: Simon Arlott <simon@octiron.net> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: sr: Fix sr_probe() missing mutex_destroySimon Arlott1-0/+1
[ Upstream commit a247e07f8dadba5da9f188aaf4f96db0302146d9 ] If the device minor cannot be allocated or the cdrom fails to be registered then the mutex should be destroyed. Link: https://lore.kernel.org/r/06e9de38-eeed-1cab-5e08-e889288935b3@0882a8b5-c6c3-11e9-b005-00805fc181fe Fixes: 51a858817dcd ("scsi: sr: get rid of sr global mutex") Signed-off-by: Simon Arlott <simon@octiron.net> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24net: dsa: lantiq_gswip: fix and improve the unsupported interface errorMartin Blumenstingl1-1/+2
[ Upstream commit 4d3da2d8d91f66988a829a18a0ce59945e8ae4fb ] While trying to use the lantiq_gswip driver on one of my boards I made a mistake when specifying the phy-mode (because the out-of-tree driver wants phy-mode "gmii" or "mii" for the internal PHYs). In this case the following error is printed multiple times: Unsupported interface: 3 While it gives at least a hint at what may be wrong it is not very user friendly. Print the human readable phy-mode and also which port is configured incorrectly (this hardware supports ports 0..6) to improve the cases where someone made a mistake. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Acked-by: Hauke Mehrtens <hauke@hauke-m.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24NTB: Fix the default port and peer numbers for legacy driversLogan Gunthorpe1-6/+2
[ Upstream commit fc8b086d9dbd57458d136c4fa70ee26f832c3a2e ] When the commit adding ntb_default_port_number() and ntb_default_peer_port_number() entered the kernel there was no users of it so it was impossible to tell what the API needed. When a user finally landed a year later (ntb_pingpong) there were more NTB topologies were created and no consideration was considered to how other drivers had changed. Now that there is a user it can be fixed to provide a sensible default for the legacy drivers that do not implement ntb_{peer_}port_number(). Seeing ntb_pingpong doesn't check error codes returning EINVAL was also not sensible. Patches for ntb_pingpong and ntb_perf follow (which are broken otherwise) to support hardware that doesn't have port numbers. This is important not only to not break support with existing drivers but for the cross link topology which, due to its perfect symmetry, cannot assign unique port numbers to each side. Fixes: 1e5301196a88 ("NTB: Add indexed ports NTB API") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Acked-by: Allen Hubbe <allenbh@gmail.com> Tested-by: Alexander Fomichev <fomichev.ru@gmail.com> Signed-off-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24NTB: ntb_pingpong: Choose doorbells based on port numberLogan Gunthorpe1-8/+6
[ Upstream commit ca93c45755da98302c93abdd788fc09113baf9e0 ] This commit fixes pingpong support for existing drivers that do not implement ntb_default_port_number() and ntb_default_peer_port_number(). This is required for hardware (like the crosslink topology of switchtec) which cannot assign reasonable port numbers to each port due to its perfect symmetry. Instead of picking the doorbell to use based on the the index of the peer, we use the peer's port number. This is a bit clearer and easier to understand. Fixes: c7aeb0afdcc2 ("NTB: ntb_pp: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Acked-by: Allen Hubbe <allenbh@gmail.com> Tested-by: Alexander Fomichev <fomichev.ru@gmail.com> Signed-off-by: Jon Mason <jdmason@kudzu.us> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24net: mdiobus: Disable preemption upon u64_stats updateAhmed S. Darwish1-0/+2
[ Upstream commit c7e261d81783387a0502878cd229327e7c54322e ] The u64_stats mechanism uses sequence counters to protect against 64-bit values tearing on 32-bit architectures. Updating u64_stats is thus a sequence counter write side critical section where preemption must be disabled. For mdiobus_stats_acct(), disable preemption upon the u64_stats update. It is called from process context through mdiobus_read() and mdiobus_write(). Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Ahmed S. Darwish <a.darwish@linutronix.de> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24yam: fix possible memory leak in yam_init_driverWang Hai1-0/+1
[ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ] If register_netdev(dev) fails, free_netdev(dev) needs to be called, otherwise a memory leak will occur. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24crypto: omap-sham - huge buffer access fixesTero Kristo1-2/+9
[ Upstream commit 6395166d7a19019d5e9574eb9ecdaf0028abb887 ] The ctx internal buffer can only hold buflen amount of data, don't try to copy over more than that. Also, initialize the context sg pointer if we only have data in the context internal buffer, this can happen when closing a hash with certain data amounts. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24drm/nouveau: gr/gk20a: Use firmware version 0Thierry Reding1-1/+1
[ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ] Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW") Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24clk: sprd: fix compile-testingArnd Bergmann1-1/+1
[ Upstream commit b5f73d47f34b238221ac771b5fe4907df621d7cb ] I got a build failure with CONFIG_ARCH_SPRD=m when the main portion of the clock driver failed to get linked into the kernel: ERROR: modpost: "sprd_pll_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_comp_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_clk_probe" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_clk_regmap_init" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! This is a combination of two trivial bugs: - A platform should not be 'tristate', it should be a 'bool' symbol like the other platforms, if only for consistency, and to avoid surprises like this one. - The clk Makefile does not traverse into the sprd subdirectory if the platform is disabled but the drivers are enabled for compile-testing. Fixing either of the two would be sufficient to address the link failure, but for correctness, both need to be changed. Fixes: 2b1b799d7630 ("arm64: change ARCH_SPRD Kconfig to tristate") Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure") Acked-by: Chunyan Zhang <chunyan.zhang@unisoc.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed caseNavid Emamdoost1-2/+6
[ Upstream commit ca162ce98110b98e7d97b7157328d34dcfdd40a9 ] Even in failed case of pm_runtime_get_sync(), the usage_count is incremented. In order to keep the usage_count with correct value call appropriate pm_runtime_put(). Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24RDMA/core: Fix several reference count leaks.Qiushi Wu1-5/+5
[ Upstream commit 0b8e125e213204508e1b3c4bdfe69713280b7abd ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") fixed a similar problem. Link: https://lore.kernel.org/r/20200528030231.9082-1-wu000273@umn.edu Signed-off-by: Qiushi Wu <wu000273@umn.edu> Reviewed-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24PCI: vmd: Filter resource type bits from shadow registerJon Derrick1-2/+4
[ Upstream commit 3e5095eebe015d5a4d566aa5e03c8621add5f0a7 ] Versions of VMD with the Host Physical Address shadow register use this register to calculate the bus address offset needed to do guest passthrough of the domain. This register shadows the Host Physical Address registers including the resource type bits. After calculating the offset, the extra resource type bits lead to the VMD resources being over-provisioned at the front and under-provisioned at the back. Example: pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit] Expected: pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit] If other devices are mapped in the over-provisioned front, it could lead to resource conflict issues with VMD or those devices. Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes") Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24IB/mlx5: Fix DEVX support for MLX5_CMD_OP_INIT2INIT_QP commandMark Zhang1-0/+4
[ Upstream commit d246a3061528be6d852156d25c02ea69d6db7e65 ] The commit citied in the Fixes line wasn't complete and solved only part of the problems. Update the mlx5_ib to properly support MLX5_CMD_OP_INIT2INIT_QP command in the DEVX, that is required when modify the QP tx_port_affinity. Fixes: 819f7427bafd ("RDMA/mlx5: Add init2init as a modify command") Link: https://lore.kernel.org/r/20200527135703.482501-1-leon@kernel.org Signed-off-by: Mark Zhang <markz@mellanox.com> Reviewed-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24clk: clk-flexgen: fix clock-critical handlingAlain Volmat1-0/+1
[ Upstream commit a403bbab1a73d798728d76931cab3ff0399b9560 ] Fixes an issue leading to having all clocks following a critical clocks marked as well as criticals. Fixes: fa6415affe20 ("clk: st: clk-flexgen: Detect critical clocks") Signed-off-by: Alain Volmat <avolmat@me.com> Link: https://lkml.kernel.org/r/20200322140740.3970-1-avolmat@me.com Reviewed-by: Patrice Chotard <patrice.chotard@st.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: vhost: Notify TCM about the maximum sg entries supported per commandSudhakar Panneerselvam1-0/+1
[ Upstream commit 5ae6a6a915033bfee79e76e0c374d4f927909edc ] vhost-scsi pre-allocates the maximum sg entries per command and if a command requires more than VHOST_SCSI_PREALLOC_SGLS entries, then that command is failed by it. This patch lets vhost communicate the max sg limit when it registers vhost_scsi_ops with TCM. With this change, TCM would report the max sg entries through "Block Limits" VPD page which will be typically queried by the SCSI initiator during device discovery. By knowing this limit, the initiator could ensure the maximum transfer length is less than or equal to what is reported by vhost-scsi. Link: https://lore.kernel.org/r/1590166317-953-1-git-send-email-sudhakar.panneerselvam@oracle.com Cc: Michael S. Tsirkin <mst@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Mike Christie <mchristi@redhat.com> Signed-off-by: Sudhakar Panneerselvam <sudhakar.panneerselvam@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited eventXiyu Yang1-0/+2
[ Upstream commit 7217e6e694da3aae6d17db8a7f7460c8d4817ebf ] In order to create or activate a new node, lpfc_els_unsol_buffer() invokes lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will return a reference of the specified lpfc_nodelist object to "ndlp" with increased refcnt. When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), causing a refcnt leak. Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS. Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn Reviewed-by: Daniel Wagner <dwagner@suse.de> Reviewed-by: James Smart <james.smart@broadcom.com> Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24clk: zynqmp: fix memory leak in zynqmp_register_clocksQuanyang Wang1-6/+9
[ Upstream commit 58b0fb86260063f86afecaebf4056c876fff2a19 ] This is detected by kmemleak running on zcu102 board: unreferenced object 0xffffffc877e48180 (size 128): comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s) hex dump (first 32 bytes): 64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1............... backtrace: [<00000000c9be883b>] __kmalloc_track_caller+0x200/0x380 [<00000000f02c3809>] kvasprintf+0x7c/0x100 [<00000000e51dde4d>] kasprintf+0x60/0x80 [<0000000092298b05>] zynqmp_register_clocks+0x29c/0x398 [<00000000faaff182>] zynqmp_clock_probe+0x3cc/0x4c0 [<000000005f5986f0>] platform_drv_probe+0x58/0xa8 [<00000000d5810136>] really_probe+0xd8/0x2a8 [<00000000f5b671be>] driver_probe_device+0x5c/0x100 [<0000000038f91fcf>] __device_attach_driver+0x98/0xb8 [<000000008a3f2ac2>] bus_for_each_drv+0x74/0xd8 [<000000001cb2783d>] __device_attach+0xe0/0x140 [<00000000c268031b>] device_initial_probe+0x24/0x30 [<000000006998de4b>] bus_probe_device+0x9c/0xa8 [<00000000647ae6ff>] device_add+0x3c0/0x610 [<0000000071c14bb8>] of_device_add+0x40/0x50 [<000000004bb5d132>] of_platform_device_create_pdata+0xbc/0x138 This is because that when num_nodes is larger than 1, clk_out is allocated using kasprintf for these nodes but only the last node's clk_out is freed. Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lkml.kernel.org/r/1583185843-20707-5-git-send-email-jolly.shah@xilinx.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: cxgb3i: Fix some leaks in init_act_open()Dan Carpenter1-4/+14
[ Upstream commit b6170a49c59c27a10efed26c5a2969403e69aaba ] There wasn't any clean up done if cxgb3_alloc_atid() failed and also the original code didn't release "csk->l2t". Link: https://lore.kernel.org/r/20200521121221.GA247492@mwanda Fixes: 6f7efaabefeb ("[SCSI] cxgb3i: change cxgb3i to use libcxgbi") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24mfd: wm8994: Fix driver operation if loaded as modulesMarek Szyprowski1-0/+1
[ Upstream commit d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ] WM8994 chip has built-in regulators, which might be used for chip operation. They are controlled by a separate wm8994-regulator driver, which should be loaded before this driver calls regulator_get(), because that driver also provides consumer-supply mapping for the them. If that driver is not yet loaded, regulator core substitute them with dummy regulator, what breaks chip operation, because the built-in regulators are never enabled. Fix this by annotating this driver with MODULE_SOFTDEP() "pre" dependency to "wm8994_regulator" module. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Acked-by: Charles Keepax <ckeepax@opensource.cirrus.com> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24usb: gadget: core: sync interrupt before unbind the udcPeter Chen1-0/+2
[ Upstream commit 3c73bc52195def14165c3a7d91bdbb33b51725f5 ] The threaded interrupt handler may still be called after the usb_gadget_disconnect is called, it causes the structures used at interrupt handler was freed before it uses, eg the usb_request. This issue usually occurs we remove the udc function during the transfer. Below is the example when doing stress test for android switch function, the EP0's request is freed by .unbind (configfs_composite_unbind -> composite_dev_cleanup), but the threaded handler accesses this request during handling setup packet request. In fact, there is no protection between unbind the udc and udc interrupt handling, so we have to avoid the interrupt handler is occurred or scheduled during the .unbind flow. init: Sending signal 9 to service 'adbd' (pid 18077) process group... android_work: did not send uevent (0 0 000000007bec2039) libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms init: Service 'adbd' (pid 18077) received signal 9 init: Sending signal 9 to service 'adbd' (pid 18077) process group... libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14) init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1. init: starting service 'adbd'... read descriptors read strings Unable to handle kernel read from unreadable memory at virtual address 000000000000002a android_work: sent uevent USB_STATE=CONNECTED Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000 using random self ethernet address [000000000000002a] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 #92 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 00400085 (nzcv daIf +PAN -UAO) using random host ethernet address pc : composite_setup+0x5c/0x1730 lr : android_setup+0xc0/0x148 sp : ffff80001349bba0 x29: ffff80001349bba0 x28: ffff00083a50da00 x27: ffff8000124e6000 x26: ffff800010177950 x25: 0000000000000040 x24: ffff000834e18010 x23: 0000000000000000 x22: 0000000000000000 x21: ffff00083a50da00 x20: ffff00082e75ec40 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 x11: ffff80001180fb58 x10: 0000000000000040 x9 : ffff8000120fc980 x8 : 0000000000000000 x7 : ffff00083f98df50 x6 : 0000000000000100 x5 : 00000307e8978431 x4 : ffff800011386788 x3 : 0000000000000000 x2 : ffff800012342000 x1 : 0000000000000000 x0 : ffff800010c6d3a0 Call trace: composite_setup+0x5c/0x1730 android_setup+0xc0/0x148 cdns3_ep0_delegate_req+0x64/0x90 cdns3_check_ep0_interrupt_proceed+0x384/0x738 cdns3_device_thread_irq_handler+0x124/0x6e0 cdns3_thread_irq+0x94/0xa0 irq_thread_fn+0x30/0xa0 irq_thread+0x150/0x248 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61) ---[ end trace c685db37f8773fba ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0002,20002008 Memory Limit: none Rebooting in 5 seconds.. Reviewed-by: Jun Li <jun.li@nxp.com> Signed-off-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registrationAndy Shevchenko1-9/+16
[ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ] Add missed acpi_gpiochip_free_interrupts() call when unregistering ports. While at it, drop extra check to call acpi_gpiochip_request_interrupts(). There is no need to have an additional check to call acpi_gpiochip_request_interrupts(). Even without any interrupts available the registered ACPI Event handlers can be useful for debugging purposes. Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Serge Semin <fancer.lancer@gmail.com> Acked-by: Serge Semin <fancer.lancer@gmail.com> Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24usb: cdns3: Fix runtime PM imbalance on errorDinghao Liu1-2/+1
[ Upstream commit e5b913496099527abe46e175e5e2c844367bded0 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Reviewed-by: Peter Chen <peter.chen@nxp.com> Signed-off-by: Dinghao Liu <dinghao.liu@zju.edu.cn> Signed-off-by: Felipe Balbi <balbi@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24habanalabs: don't allow hard reset with open processesOmer Shpigelman1-6/+11
[ Upstream commit 36fafe87edd636292a4ed6a3af9608f2c7d0d0fb ] When the MMU is heavily used by the engines, unmapping might take a lot of time due to a full MMU cache invalidation done as part of the unmap flow. Hence we might not be able to kill all open processes before going to hard reset the device, as it involves unmapping of all user memory. In case of a failure in killing all open processes, we should stop the hard reset flow as it might lead to a kernel crash - one thread (killing of a process) is updating MMU structures that other thread (hard reset) is freeing. Stopping a hard reset flow leaves the device as nonoperational and the user can then initiate a hard reset via sysfs to reinitialize the device. Signed-off-by: Omer Shpigelman <oshpigelman@habana.ai> Reviewed-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24PCI: pci-bridge-emul: Fix PCIe bit conflictsJon Derrick1-3/+3
[ Upstream commit c88d19181771bd189147681ef38fc1533ebeff4c ] This patch fixes two bit conflicts in the pci-bridge-emul driver: 1. Bit 3 of Device Status (19 of Device Control) is marked as both Write-1-to-Clear and Read-Only. It should be Write-1-to-Clear. The Read-Only and Reserved bitmasks are shifted by 1 bit due to this error. 2. Bit 12 of Slot Control is marked as both Read-Write and Reserved. It should be Read-Write. Link: https://lore.kernel.org/r/20200511162117.6674-2-jonathan.derrick@intel.com Signed-off-by: Jon Derrick <jonathan.derrick@intel.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24scsi: hisi_sas: Do not reset phy timer to wait for stray phy upLuo Jiaxing1-1/+4
[ Upstream commit e16b9ed61e078d836a0f24a82080cf29d7539c7e ] We found out that after phy up, the hardware reports another oob interrupt but did not follow a phy up interrupt: oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout We run link reset when wait phy up timeout, and it send a normal disk into reset processing. So we made some circumvention action in the code, so that this abnormal oob interrupt will not start the timer to wait for phy up. Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.com Signed-off-by: Luo Jiaxing <luojiaxing@huawei.com> Signed-off-by: John Garry <john.garry@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24RDMA/mlx5: Add init2init as a modify commandAharon Landau1-0/+1
[ Upstream commit 819f7427bafd494ef7ca4942ec6322db20722d7b ] Missing INIT2INIT entry in the list of modify commands caused DEVX applications to be unable to modify_qp for this transition state. Add the MLX5_CMD_OP_INIT2INIT_QP opcode to the list of allowed DEVX opcodes. Fixes: e662e14d801b ("IB/mlx5: Add DEVX support for modify and query commands") Link: https://lore.kernel.org/r/20200513095550.211345-1-leon@kernel.org Signed-off-by: Aharon Landau <aharonl@mellanox.com> Reviewed-by: Maor Gottlieb <maorg@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24coresight: tmc: Fix TMC mode read in tmc_read_prepare_etb()Sai Prakash Ranjan1-8/+8
[ Upstream commit 347adb0d6385c3220dc01ab61807a5b1892901cc ] On some QCOM platforms like SC7180, SDM845 and SM8150, reading TMC mode register without proper coresight power management can lead to async exceptions like the one in the call trace below in tmc_read_prepare_etb(). This can happen if the user tries to read the TMC etf data via device node without setting up source and the sink first. Fix this by having a check for coresight sysfs mode before reading TMC mode management register. Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 2605 Comm: hexdump Tainted: G S 5.4.30 #122 Call trace: dump_backtrace+0x0/0x188 show_stack+0x20/0x2c dump_stack+0xdc/0x144 panic+0x168/0x36c panic+0x0/0x36c arm64_serror_panic+0x78/0x84 do_serror+0x130/0x138 el1_error+0x84/0xf8 tmc_read_prepare_etb+0x88/0xb8 tmc_open+0x40/0xd8 misc_open+0x120/0x158 chrdev_open+0xb8/0x1a4 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3e8 __arm64_compat_sys_openat+0x28/0x34 el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Fixes: 4525412a5046 ("coresight: tmc: making prepare/unprepare functions generic") Reported-by: Stephen Boyd <swboyd@chromium.org> Suggested-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20200518180242.7916-14-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24vfio/pci: fix memory leaks in alloc_perm_bits()Qian Cai1-2/+5
[ Upstream commit 3e63b94b6274324ff2e7d8615df31586de827c4e ] vfio_pci_disable() calls vfio_config_free() but forgets to call free_perm_bits() resulting in memory leaks, unreferenced object 0xc000000c4db2dee0 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125 (inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180 (inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241 (inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468 (inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707 [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 unreferenced object 0xc000000c4db2e330 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Signed-off-by: Qian Cai <cai@lca.pw> [aw: rolled in follow-up patch] Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24ps3disk: use the default segment boundaryEmmanuel Nicolet1-1/+0
[ Upstream commit 720bc316690bd27dea9d71510b50f0cd698ffc32 ] Since commit dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count"), the kernel will bug_on on the PS3 because bio_split() is called with sectors == 0: kernel BUG at block/bio.c:1853! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3 Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \ ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1 NIP: c00000000027d0d0 LR: c00000000027d0b0 CTR: 0000000000000000 REGS: c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4) MSR: 8000000000028032 <SF,EE,IR,DR,RI> CR: 44008240 XER: 20000000 IRQMASK: 0 GPR00: c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300 GPR04: 0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff GPR08: 0000000000000000 0000000000000001 0000000000000000 000000000000ffff GPR12: 0000000000000000 c0000000008ef000 000000000000003e 0000000000080001 GPR16: 0000000000000100 000000000000ffff 0000000000000000 0000000000000004 GPR20: c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080 GPR24: c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0 GPR28: c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000 NIP [c00000000027d0d0] .bio_split+0x28/0xac LR [c00000000027d0b0] .bio_split+0x8/0xac Call Trace: [c00000000135b120] [c00000000027d130] .bio_split+0x88/0xac (unreliable) [c00000000135b1b0] [c000000000289368] .__blk_queue_split+0x11c/0x53c [c00000000135b2d0] [c00000000028f614] .blk_mq_make_request+0x80/0x7d4 [c00000000135b3d0] [c000000000283a8c] .generic_make_request+0x118/0x294 [c00000000135b4b0] [c000000000283d34] .submit_bio+0x12c/0x174 [c00000000135b580] [c000000000205a44] .mpage_bio_submit+0x3c/0x4c [c00000000135b600] [c000000000206184] .mpage_readpages+0xa4/0x184 [c00000000135b750] [c0000000001ff8fc] .blkdev_readpages+0x24/0x38 [c00000000135b7c0] [c0000000001589f0] .read_pages+0x6c/0x1a8 [c00000000135b8b0] [c000000000158c74] .__do_page_cache_readahead+0x118/0x184 [c00000000135b9b0] [c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8 [c00000000135ba50] [c00000000014fc24] .generic_file_read_iter+0x1d8/0x830 [c00000000135bb50] [c0000000001ffadc] .blkdev_read_iter+0x40/0x5c [c00000000135bbc0] [c0000000001b9e00] .new_sync_read+0x144/0x1a0 [c00000000135bcd0] [c0000000001bc454] .vfs_read+0xa0/0x124 [c00000000135bd70] [c0000000001bc7a4] .ksys_read+0x70/0xd8 [c00000000135be20] [c00000000000a524] system_call+0x5c/0x70 Instruction dump: 7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0 7c7d1b78 79290fe0 7cc53378 69290001 <0b090000> 81230028 7bca0020 7929ba62 [ end trace 313fec760f30aa1f ]--- The problem originates from setting the segment boundary of the request queue to -1UL. This makes get_max_segment_size() return zero when offset is zero, whatever the max segment size. The test with BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows to zero in the return statement. Not setting the segment boundary and using the default value (BLK_SEG_BOUNDARY_MASK) fixes the problem. Signed-off-by: Emmanuel Nicolet <emmanuel.nicolet@gmail.com> Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only ↵Pali Rohár1-4/+0
register [ Upstream commit 90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ] Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org Tested-by: Tomasz Maciej Nowak <tmn505@gmail.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Rob Herring <robh@kernel.org> Acked-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24clk: renesas: cpg-mssr: Fix STBCR suspend/resume handlingGeert Uytterhoeven1-3/+5
[ Upstream commit ace342097768e35fd41934285604fa97da1e235a ] On SoCs with Standby Control Registers (STBCRs) instead of Module Stop Control Registers (MSTPCRs), the suspend handler saves the wrong registers, and the resume handler prints the wrong register in an error message. Fortunately this cannot happen yet, as the suspend/resume code is used on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not use PSCI. Still, it is better to fix this, to avoid this becoming a problem in the future. Distinguish between STBCRs and MSTPCRs where needed. Replace the useless printing of the virtual register address in the resume error message by printing the register index. Fixes: fde35c9c7db5732c ("clk: renesas: cpg-mssr: Add R7S9210 support") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20200507074713.30113-1-geert+renesas@glider.be Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2Lars Povlsen1-1/+2
[ Upstream commit 0b47afc65453a70bc521e251138418056f65793f ] This fixes a problem with using the GPIO as an interrupt on Jaguar2 (and similar), as the register layout of the platforms with 64 GPIO's are pairwise, such that the original offset must be multiplied with the platform stride. Fixes: da801ab56ad8 pinctrl: ocelot: add MSCC Jaguar2 support. Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com> Link: https://lore.kernel.org/r/20200513125532.24585-4-lars.povlsen@microchip.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24RDMA/srpt: Fix disabling device managementKamal Heib1-2/+6
[ Upstream commit 23bbd5818e2b0d265aa1835e66f5055f63a8fa4c ] Avoid disabling device management for devices that don't support Management datagrams (MADs) by checking if the "mad_agent" pointer is initialized before calling ib_modify_port, also fix the error flow in srpt_refresh_port() to disable device management if ib_register_mad_agent() fail. Fixes: 09f8a1486dca ("RDMA/srpt: Fix handling of SR-IOV and iWARP ports") Link: https://lore.kernel.org/r/20200514114720.141139-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24RDMA/uverbs: Fix create WQ to use the given user handleYishai Hadas1-2/+1
[ Upstream commit dbd67252869ba58d086edfa14113e10f8059b97e ] Fix create WQ to use the given user handle, in addition dropped some duplicated code from this flow. Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema") Fixes: f213c0527210 ("IB/uverbs: Add WQ support") Link: https://lore.kernel.org/r/20200506082444.14502-9-leon@kernel.org Signed-off-by: Yishai Hadas <yishaih@mellanox.com> Signed-off-by: Leon Romanovsky <leonro@mellanox.com> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24dm mpath: switch paths in dm_blk_ioctl() code pathMartin Wilck1-1/+1
[ Upstream commit 2361ae595352dec015d14292f1b539242d8446d6 ] SCSI LUN passthrough code such as qemu's "scsi-block" device model pass every IO to the host via SG_IO ioctls. Currently, dm-multipath calls choose_pgpath() only in the block IO code path, not in the ioctl code path (unless current_pgpath is NULL). This has the effect that no path switching and thus no load balancing is done for SCSI-passthrough IO, unless the active path fails. Fix this by using the same logic in multipath_prepare_ioctl() as in multipath_clone_and_map(). Note: The allegedly best path selection algorithm, service-time, still wouldn't work perfectly, because the io size of the current request is always set to 0. Changing that for the IO passthrough case would require the ioctl cmd and arg to be passed to dm's prepare_ioctl() method. Signed-off-by: Martin Wilck <mwilck@suse.com> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-06-24misc: fastrpc: fix potential fastrpc_invoke_ctx leakSrinivas Kandagatla1-1/+8
[ Upstream commit 74003385cf716f1b88cc7753ca282f5493f204a2 ] fastrpc_invoke_ctx can have refcount of 2 in error path where rpmsg_send() fails to send invoke message. decrement the refcount properly in the error path to fix this leak. This also fixes below static checker warning: drivers/misc/fastrpc.c:990 fastrpc_internal_invoke() warn: 'ctx->refcount.refcount.ref.counter' not decremented on lines: 990. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20200512110930.2550-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-03 05:43:59 +0300