summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2022-01-27clk: qcom: gcc-sc7280: Mark gcc_cfg_noc_lpass_clk always enabledTaniya Das1-1/+1
[ Upstream commit 9c337073d9d81a145434b22f42dc3128ecd17730 ] The gcc cfg noc lpass clock is required to be always enabled for the LPASS core and audio drivers to be functional. Fixes: a3cc092196ef ("clk: qcom: Add Global Clock controller (GCC) driver for SC7280") Signed-off-by: Taniya Das <tdas@codeaurora.org> Link: https://lore.kernel.org/r/1640018638-19436-4-git-send-email-tdas@codeaurora.org Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/cxgb4: Set queue pair state when being queriedKamal Heib1-0/+1
[ Upstream commit e375b9c92985e409c4bb95dd43d34915ea7f5e28 ] The API for ib_query_qp requires the driver to set cur_qp_state on return, add the missing set. Fixes: 67bbc05512d8 ("RDMA/cxgb4: Add query_qp support") Link: https://lore.kernel.org/r/20211220152530.60399-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27misc: lattice-ecp3-config: Fix task hung when firmware load failedWei Yongjun1-6/+6
[ Upstream commit fcee5ce50bdb21116711e38635e3865594af907e ] When firmware load failed, kernel report task hung as follows: INFO: task xrun:5191 blocked for more than 147 seconds. Tainted: G W 5.16.0-rc5-next-20211220+ #11 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:xrun state:D stack: 0 pid: 5191 ppid: 270 flags:0x00000004 Call Trace: __schedule+0xc12/0x4b50 kernel/sched/core.c:4986 schedule+0xd7/0x260 kernel/sched/core.c:6369 (discriminator 1) schedule_timeout+0x7aa/0xa80 kernel/time/timer.c:1857 wait_for_completion+0x181/0x290 kernel/sched/completion.c:85 lattice_ecp3_remove+0x32/0x40 drivers/misc/lattice-ecp3-config.c:221 spi_remove+0x72/0xb0 drivers/spi/spi.c:409 lattice_ecp3_remove() wait for signals from firmware loading, but when load failed, firmware_load() does not send this signal. This cause device remove hung. Fix it by sending signal even if load failed. Fixes: 781551df57c7 ("misc: Add Lattice ECP3 FPGA configuration via SPI") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Link: https://lore.kernel.org/r/20211228125522.3122284-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27phy: cadence: Sierra: Fix to get correct parent for mux clocksSwapnil Jakhade1-5/+26
[ Upstream commit da08aab940092a050a4fb2857ed9479d2b0e03c4 ] Fix get_parent() callback to return the correct index of the parent for PLL_CMNLC1 clock. Add a separate table of register values corresponding to the parent index for PLL_CMNLC1. Update set_parent() callback accordingly. Fixes: 28081b72859f ("phy: cadence: Sierra: Model PLL_CMNLC and PLL_CMNLC1 as clocks (mux clocks)") Signed-off-by: Swapnil Jakhade <sjakhade@cadence.com> Reviewed-by: Aswath Govindraju <a-govindraju@ti.com> Link: https://lore.kernel.org/r/20211223060137.9252-12-sjakhade@cadence.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27ASoC: mediatek: Check for error clk pointerJiasheng Jiang1-4/+11
[ Upstream commit 9de2b9286a6dd16966959b3cb34fc2ddfd39213e ] Yes, you are right and now the return code depending on the init_clks(). Fixes: 6078c651947a ("soc: mediatek: Refine scpsys to support multiple platform") Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20211222015157.1025853-1-jiasheng@iscas.ac.cn Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27phy: uniphier-usb3ss: fix unintended writing zeros to PHY registerRyuta NAKANISHI1-4/+6
[ Upstream commit 898c7a9ec81620125f2463714a0f4dea18ad6e54 ] Similar to commit 4a90bbb478db ("phy: uniphier-pcie: Fix updating phy parameters"), in function uniphier_u3ssphy_set_param(), unintentionally write zeros to other fields when writing PHY registers. Fixes: 5ab43d0f8697 ("phy: socionext: add USB3 PHY driver for UniPhier SoC") Signed-off-by: Ryuta NAKANISHI <nakanishi.ryuta@socionext.com> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1640150369-4134-1-git-send-email-hayashi.kunihiko@socionext.com Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27scsi: block: pm: Always set request queue runtime active in ↵Alan Stern1-1/+1
blk_post_runtime_resume() [ Upstream commit 6e1fcab00a23f7fe9f4fe9704905a790efa1eeab ] John Garry reported a deadlock that occurs when trying to access a runtime-suspended SATA device. For obscure reasons, the rescan procedure causes the link to be hard-reset, which disconnects the device. The rescan tries to carry out a runtime resume when accessing the device. scsi_rescan_device() holds the SCSI device lock and won't release it until it can put commands onto the device's block queue. This can't happen until the queue is successfully runtime-resumed or the device is unregistered. But the runtime resume fails because the device is disconnected, and __scsi_remove_device() can't do the unregistration because it can't get the device lock. The best way to resolve this deadlock appears to be to allow the block queue to start running again even after an unsuccessful runtime resume. The idea is that the driver or the SCSI error handler will need to be able to use the queue to resolve the runtime resume failure. This patch removes the err argument to blk_post_runtime_resume() and makes the routine act as though the resume was successful always. This fixes the deadlock. Link: https://lore.kernel.org/r/1639999298-244569-4-git-send-email-chenxiang66@hisilicon.com Fixes: e27829dc92e5 ("scsi: serialize ->rescan against ->remove") Reported-and-tested-by: John Garry <john.garry@huawei.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Xiang Chen <chenxiang66@hisilicon.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27efi: apply memblock cap after memblock_add()Pingfan Liu2-1/+6
[ Upstream commit b398123bff3bcbc1facb0f29bf6e7b9f1bc55931 ] On arm64, during kdump kernel saves vmcore, it runs into the following bug: ... [ 15.148919] usercopy: Kernel memory exposure attempt detected from SLUB object 'kmem_cache_node' (offset 0, size 4096)! [ 15.159707] ------------[ cut here ]------------ [ 15.164311] kernel BUG at mm/usercopy.c:99! [ 15.168482] Internal error: Oops - BUG: 0 [#1] SMP [ 15.173261] Modules linked in: xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 sha1_ce sbsa_gwdt ast i2c_algo_bit drm_vram_helper drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec drm_ttm_helper ttm drm nvme nvme_core xgene_hwmon i2c_designware_platform i2c_designware_core dm_mirror dm_region_hash dm_log dm_mod overlay squashfs zstd_decompress loop [ 15.206186] CPU: 0 PID: 542 Comm: cp Not tainted 5.16.0-rc4 #1 [ 15.212006] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F12 (SCP: 1.5.20210426) 05/13/2021 [ 15.221125] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 15.228073] pc : usercopy_abort+0x9c/0xa0 [ 15.232074] lr : usercopy_abort+0x9c/0xa0 [ 15.236070] sp : ffff8000121abba0 [ 15.239371] x29: ffff8000121abbb0 x28: 0000000000003000 x27: 0000000000000000 [ 15.246494] x26: 0000000080000400 x25: 0000ffff885c7000 x24: 0000000000000000 [ 15.253617] x23: 000007ff80400000 x22: ffff07ff80401000 x21: 0000000000000001 [ 15.260739] x20: 0000000000001000 x19: ffff07ff80400000 x18: ffffffffffffffff [ 15.267861] x17: 656a626f2042554c x16: 53206d6f72662064 x15: 6574636574656420 [ 15.274983] x14: 74706d6574746120 x13: 2129363930342065 x12: 7a6973202c302074 [ 15.282105] x11: ffffc8b041d1b148 x10: 00000000ffff8000 x9 : ffffc8b04012812c [ 15.289228] x8 : 00000000ffff7fff x7 : ffffc8b041d1b148 x6 : 0000000000000000 [ 15.296349] x5 : 0000000000000000 x4 : 0000000000007fff x3 : 0000000000000000 [ 15.303471] x2 : 0000000000000000 x1 : ffff07ff8c064800 x0 : 000000000000006b [ 15.310593] Call trace: [ 15.313027] usercopy_abort+0x9c/0xa0 [ 15.316677] __check_heap_object+0xd4/0xf0 [ 15.320762] __check_object_size.part.0+0x160/0x1e0 [ 15.325628] __check_object_size+0x2c/0x40 [ 15.329711] copy_oldmem_page+0x7c/0x140 [ 15.333623] read_from_oldmem.part.0+0xfc/0x1c0 [ 15.338142] __read_vmcore.constprop.0+0x23c/0x350 [ 15.342920] read_vmcore+0x28/0x34 [ 15.346309] proc_reg_read+0xb4/0xf0 [ 15.349871] vfs_read+0xb8/0x1f0 [ 15.353088] ksys_read+0x74/0x100 [ 15.356390] __arm64_sys_read+0x28/0x34 ... This bug introduced by commit b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling"), which moves memblock_cap_memory_range() to fdt, but it breaches the rules that memblock_cap_memory_range() should come after memblock_add() etc as said in commit e888fa7bb882 ("memblock: Check memory add/cap ordering"). As a consequence, the virtual address set up by copy_oldmem_page() does not bail out from the test of virt_addr_valid() in check_heap_object(), and finally hits the BUG_ON(). Since memblock allocator has no idea about when the memblock is fully populated, while efi_init() is aware, so tackling this issue by calling the interface early_init_dt_check_for_usable_mem_range() exposed by of/fdt. Fixes: b261dba2fdb2 ("arm64: kdump: Remove custom linux,usable-memory-range handling") Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Zhen Lei <thunder.leizhen@huawei.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Frank Rowand <frowand.list@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Nick Terrell <terrelln@fb.com> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211215021348.8766-1-kernelfans@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27of: fdt: Aggregate the processing of "linux,usable-memory-range"Zhen Lei1-6/+13
[ Upstream commit 8347b41748c3019157312fbe7f8a6792ae396eb7 ] Currently, we parse the "linux,usable-memory-range" property in early_init_dt_scan_chosen(), to obtain the specified memory range of the crash kernel. We then reserve the required memory after early_init_dt_scan_memory() has identified all available physical memory. Because the two pieces of code are separated far, the readability and maintainability are reduced. So bring them together. Suggested-by: Rob Herring <robh@kernel.org> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> (change the prototype of early_init_dt_check_for_usable_mem_range(), in order to use it outside) Signed-off-by: Pingfan Liu <kernelfans@gmail.com> Tested-by: Dave Kleikamp <dave.kleikamp@oracle.com> Acked-by: John Donnelly <john.p.donnelly@oracle.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: linux-arm-kernel@lists.infradead.org To: devicetree@vger.kernel.org To: linux-efi@vger.kernel.org Signed-off-by: Rob Herring <robh@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/iova: Fix race between FQ timeout and teardownXiongfeng Wang1-2/+1
[ Upstream commit d7061627d701c90e1cac1e1e60c45292f64f3470 ] It turns out to be possible for hotplugging out a device to reach the stage of tearing down the device's group and default domain before the domain's flush queue has drained naturally. At this point, it is then possible for the timeout to expire just before the del_timer() call in free_iova_flush_queue(), such that we then proceed to free the FQ resources while fq_flush_timeout() is still accessing them on another CPU. Crashes due to this have been observed in the wild while removing NVMe devices. Close the race window by using del_timer_sync() to safely wait for any active timeout handler to finish before we start to free things. We already avoid any locking in free_iova_flush_queue() since the FQ is supposed to be inactive anyway, so the potential deadlock scenario does not apply. Fixes: 9a005a800ae8 ("iommu/iova: Add flush timer") Reviewed-by: John Garry <john.garry@huawei.com> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> [ rm: rewrite commit message ] Signed-off-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/0a365e5b07f14b7344677ad6a9a734966a8422ce.1639753638.git.robin.murphy@arm.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/amd: Remove useless irq affinity notifierMaxim Levitsky1-2/+0
[ Upstream commit 575f5cfb13c84f324f9898383fa4a5694e53c9ef ] iommu->intcapxt_notify field is no longer used after a switch to a separate domain was done Fixes: d1adcfbb520c ("iommu/amd: Fix IOMMU interrupt generation in X2APIC mode") Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20211123161038.48009-6-mlevitsk@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/amd: X2apic mode: mask/unmask interrupts on suspend/resumeMaxim Levitsky1-1/+7
[ Upstream commit 1980105e3cfc2215c75b4f6b172661d675c467d1 ] Use IRQCHIP_MASK_ON_SUSPEND to make the core irq code to mask the iommu interrupt on suspend and unmask it on the resume. Since now the unmask function updates the INTX settings, that will restore them on resume from s3/s4. Since IRQCHIP_MASK_ON_SUSPEND is only effective for interrupts which are not wakeup sources, remove IRQCHIP_SKIP_SET_WAKE flag and instead implement a dummy .irq_set_wake which doesn't allow the interrupt to become a wakeup source. Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20211123161038.48009-5-mlevitsk@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/amd: X2apic mode: setup the INTX registers on mask/unmaskMaxim Levitsky1-32/+33
[ Upstream commit 4691f79d62a637958f7b5f55c232a65399500b7a ] This is more logically correct and will also allow us to to use mask/unmask logic to restore INTX setttings after the resume from s3/s4. Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20211123161038.48009-4-mlevitsk@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/amd: X2apic mode: re-enable after resumeMaxim Levitsky1-1/+4
[ Upstream commit 01b297a48a26bcb96769505ac948db4603b72bd1 ] Otherwise it is guaranteed to not work after the resume... Fixes: 66929812955bb ("iommu/amd: Add support for X2APIC IOMMU interrupts") Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20211123161038.48009-3-mlevitsk@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/amd: Restore GA log/tail pointer on host resumeMaxim Levitsky1-16/+15
[ Upstream commit a8d4a37d1bb93608501d0d0545f902061152669a ] This will give IOMMU GA log a chance to work after resume from s3/s4. Fixes: 8bda0cfbdc1a6 ("iommu/amd: Detect and initialize guest vAPIC log") Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Link: https://lore.kernel.org/r/20211123161038.48009-2-mlevitsk@redhat.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27dmaengine: pxa/mmp: stop referencing config->slave_idArnd Bergmann2-13/+0
[ Upstream commit 134c37fa250a87a7e77c80a7c59ae16c462e46e0 ] The last driver referencing the slave_id on Marvell PXA and MMP platforms was the SPI driver, but this stopped doing so a long time ago, so the TODO from the earlier patch can no be removed. Fixes: b729bf34535e ("spi/pxa2xx: Don't use slave_id of dma_slave_config") Fixes: 13b3006b8ebd ("dma: mmp_pdma: add filter function") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20211122222203.4103644-7-arnd@kernel.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27clk: stm32: Fix ltdc's clock turn off by clk_disable_unused() after system ↵Dillon Min1-4/+0
enter shell [ Upstream commit 6fc058a72f3b7b07fc4de6d66ad1f68951b00f6e ] stm32's clk driver register two ltdc gate clk to clk core by clk_hw_register_gate() and clk_hw_register_composite() first: 'stm32f429_gates[]', clk name is 'ltdc', which no user to use. second: 'stm32f429_aux_clk[]', clk name is 'lcd-tft', used by ltdc driver both of them point to the same offset of stm32's RCC register. after kernel enter console, clk core turn off ltdc's clk as 'stm32f429_gates[]' is no one to use. but, actually 'stm32f429_aux_clk[]' is in use. stm32f469/746/769 have the same issue, fix it. Fixes: daf2d117cbca ("clk: stm32f4: Add lcd-tft clock") Link: https://lore.kernel.org/linux-arm-kernel/1590564453-24499-7-git-send-email-dillon.minfei@gmail.com/ Link: https://lore.kernel.org/lkml/CAPTRvHkf0cK_4ZidM17rPo99gWDmxgqFt4CDUjqFFwkOeQeFDg@mail.gmail.com/ Signed-off-by: Dillon Min <dillon.minfei@gmail.com> Reviewed-by: Patrice Chotard <patrice.chotard@foss.st.com> Acked-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Acked-by: Stephen Boyd <sboyd@kernel.org> Link: https://lore.kernel.org/r/1635232282-3992-10-git-send-email-dillon.minfei@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27of: unittest: 64 bit dma address test requires arch supportFrank Rowand1-2/+3
[ Upstream commit 9fd4cf5d3571b27d746b8ead494a3f051485b679 ] If an architecture does not support 64 bit dma addresses then testing for an expected dma address >= 0x100000000 will fail. Fixes: e0d072782c73 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Signed-off-by: Frank Rowand <frank.rowand@sony.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211212221852.233295-1-frowand.list@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27of: unittest: fix warning on PowerPC frame size warningJim Quinlan1-4/+12
[ Upstream commit a8d61a9112ad0c9216ab45d050991e07bc4f3408 ] The struct device variable "dev_bogus" was triggering this warning on a PowerPC build: drivers/of/unittest.c: In function 'of_unittest_dma_ranges_one.constprop': [...] >> The frame size of 1424 bytes is larger than 1024 bytes [-Wframe-larger-than=] This variable is now dynamically allocated. Fixes: e0d072782c734 ("dma-mapping: introduce DMA range map, supplanting dma_pfn_offset") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Jim Quinlan <jim2101024@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Frank Rowand <frank.rowand@sony.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211210184636.7273-2-jim2101024@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/cma: Let cma_resolve_ib_dev() continue search even after empty entryAvihai Horon1-3/+9
[ Upstream commit 20679094a0161c94faf77e373fa3f7428a8e14bd ] Currently, when cma_resolve_ib_dev() searches for a matching GID it will stop searching after encountering the first empty GID table entry. This behavior is wrong since neither IB nor RoCE spec enforce tightly packed GID tables. For example, when the matching valid GID entry exists at index N, and if a GID entry is empty at index N-1, cma_resolve_ib_dev() will fail to find the matching valid entry. Fix it by making cma_resolve_ib_dev() continue searching even after encountering missing entries. Fixes: f17df3b0dede ("RDMA/cma: Add support for AF_IB to rdma_resolve_addr()") Link: https://lore.kernel.org/r/b7346307e3bb396c43d67d924348c6c496493991.1639055490.git.leonro@nvidia.com Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Mark Zhang <markzhang@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>
2022-01-27RDMA/core: Let ib_find_gid() continue search even after empty entryAvihai Horon1-1/+2
[ Upstream commit 483d805191a23191f8294bbf9b4e94836f5d92e4 ] Currently, ib_find_gid() will stop searching after encountering the first empty GID table entry. This behavior is wrong since neither IB nor RoCE spec enforce tightly packed GID tables. For example, when a valid GID entry exists at index N, and if a GID entry is empty at index N-1, ib_find_gid() will fail to find the valid entry. Fix it by making ib_find_gid() continue searching even after encountering missing entries. Fixes: 5eb620c81ce3 ("IB/core: Add helpers for uncached GID and P_Key searches") Link: https://lore.kernel.org/r/e55d331b96cecfc2cf19803d16e7109ea966882d.1639055490.git.leonro@nvidia.com Signed-off-by: Avihai Horon <avihaih@nvidia.com> Reviewed-by: Mark Zhang <markzhang@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>
2022-01-27iommu/arm-smmu-qcom: Fix TTBR0 readRob Clark1-1/+1
[ Upstream commit c31112fbd4077a51a14ff338038c82e9571dc821 ] It is a 64b register, lets not lose the upper bits. Fixes: ab5df7b953d8 ("iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211108171724.470973-1-robdclark@gmail.com Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27PCI/MSI: Fix pci_irq_vector()/pci_irq_get_affinity()Thomas Gleixner1-8/+18
[ Upstream commit 29bbc35e29d9b6347780dcacde2deb4b39344167 ] pci_irq_vector() and pci_irq_get_affinity() use the list position to find the MSI-X descriptor at a given index. That's correct for the normal case where the entry number is the same as the list position. But it's wrong for cases where MSI-X was allocated with an entries array describing sparse entry numbers into the hardware message descriptor table. That's inconsistent at best. Make it always check the entry number because that's what the zero base index really means. This change won't break existing users which use a sparse entries array for allocation because these users retrieve the Linux interrupt number from the entries array after allocation and none of them uses pci_irq_vector() or pci_irq_get_affinity(). Fixes: aff171641d18 ("PCI: Provide sensible IRQ vector alloc/free routines") Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Juergen Gross <jgross@suse.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Link: https://lore.kernel.org/r/20211206210223.929792157@linutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/qedr: Fix reporting max_{send/recv}_wr attrsKamal Heib1-0/+2
[ Upstream commit b1a4da64bfc189510e08df1ccb1c589e667dc7a3 ] Fix the wrongly reported max_send_wr and max_recv_wr attributes for user QP by making sure to save their valuse on QP creation, so when query QP is called the attributes will be reported correctly. Fixes: cecbcddf6461 ("qedr: Add support for QP verbs") Link: https://lore.kernel.org/r/20211206201314.124947-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Acked-by: Michal Kalderon <michal.kalderon@marvell.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27scsi: ufs: Fix race conditions related to driver dataBart Van Assche4-5/+7
[ Upstream commit 21ad0e49085deb22c094f91f9da57319a97188e4 ] The driver data pointer must be set before any callbacks are registered that use that pointer. Hence move the initialization of that pointer from after the ufshcd_init() call to inside ufshcd_init(). Link: https://lore.kernel.org/r/20211203231950.193369-7-bvanassche@acm.org Fixes: 3b1d05807a9a ("[SCSI] ufs: Segregate PCI Specific Code") Reported-by: Alexey Dobriyan <adobriyan@gmail.com> Tested-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27scsi: core: Fix scsi_device_max_queue_depth()Bart Van Assche1-2/+2
[ Upstream commit 4bc3bffc1a885eb5cb259e4a25146a4c7b1034e3 ] The comment above scsi_device_max_queue_depth() and also the description of commit ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") contradict the implementation of the function scsi_device_max_queue_depth(). Additionally, the maximum queue depth of a SCSI LUN never exceeds host->can_queue. Fix scsi_device_max_queue_depth() by changing max_t() into min_t(). Link: https://lore.kernel.org/r/20211203231950.193369-2-bvanassche@acm.org Fixes: ca4453213951 ("scsi: core: Make sure sdev->queue_depth is <= max(shost->can_queue, 1024)") Cc: Hannes Reinecke <hare@suse.de> Cc: Sumanesh Samanta <sumanesh.samanta@broadcom.com> Tested-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Ming Lei <ming.lei@redhat.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu/io-pgtable-arm: Fix table descriptor paddr formattingHector Martin1-4/+5
[ Upstream commit 9abe2ac834851a7d0b0756e295cf7a292c45ca53 ] Table descriptors were being installed without properly formatting the address using paddr_to_iopte, which does not match up with the iopte_deref in __arm_lpae_map. This is incorrect for the LPAE pte format, as it does not handle the high bits properly. This was found on Apple T6000 DARTs, which require a new pte format (different shift); adding support for that to paddr_to_iopte/iopte_to_paddr caused it to break badly, as even <48-bit addresses would end up incorrect in that case. Fixes: 6c89928ff7a0 ("iommu/io-pgtable-arm: Support 52-bit physical address") Acked-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Hector Martin <marcan@marcan.st> Link: https://lore.kernel.org/r/20211120031343.88034-1-marcan@marcan.st Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iommu: Extend mutex lock scope in iommu_probe_device()Lu Baolu1-1/+2
[ Upstream commit 556f99ac886635e8da15528995f06d1d7028cfca ] Extend the scope of holding group->mutex so that it can cover the default domain check/attachment and direct mappings of reserved regions. Cc: Ashish Mhetre <amhetre@nvidia.com> Fixes: 211ff31b3d33b ("iommu: Fix race condition during default domain allocation") Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com> Link: https://lore.kernel.org/r/20211108061349.1985579-1-baolu.lu@linux.intel.com Signed-off-by: Joerg Roedel <jroedel@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27binder: avoid potential data leakage when copying txnTodd Kjos1-24/+70
[ Upstream commit 6d98eb95b450a75adb4516a1d33652dc78d2b20c ] Transactions are copied from the sender to the target first and objects like BINDER_TYPE_PTR and BINDER_TYPE_FDA are then fixed up. This means there is a short period where the sender's version of these objects are visible to the target prior to the fixups. Instead of copying all of the data first, copy data only after any needed fixups have been applied. Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") Reviewed-by: Martijn Coenen <maco@android.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20211130185152.437403-3-tkjos@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27binder: fix handling of error during copyTodd Kjos1-2/+2
[ Upstream commit fe6b1869243f23a485a106c214bcfdc7aa0ed593 ] If a memory copy function fails to copy the whole buffer, a positive integar with the remaining bytes is returned. In binder_translate_fd_array() this can result in an fd being skipped due to the failed copy, but the loop continues processing fds since the early return condition expects a negative integer on error. Fix by returning "ret > 0 ? -EINVAL : ret" to handle this case. Fixes: bb4a2e48d510 ("binder: return errors from buffer copy functions") Suggested-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> Signed-off-by: Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20211130185152.437403-2-tkjos@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27char/mwave: Adjust io port register sizeKees Cook1-1/+1
[ Upstream commit f5912cc19acd7c24b2dbf65a6340bf194244f085 ] Using MKWORD() on a byte-sized variable results in OOB read. Expand the size of the reserved area so both MKWORD and MKBYTE continue to work without overflow. Silences this warning on a -Warray-bounds build: drivers/char/mwave/3780i.h:346:22: error: array subscript 'short unsigned int[0]' is partly outside array bounds of 'DSP_ISA_SLAVE_CONTROL[1]' [-Werror=array-bounds] 346 | #define MKWORD(var) (*((unsigned short *)(&var))) | ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/char/mwave/3780i.h:356:40: note: in definition of macro 'OutWordDsp' 356 | #define OutWordDsp(index,value) outw(value,usDspBaseIO+index) | ^~~~~ drivers/char/mwave/3780i.c:373:41: note: in expansion of macro 'MKWORD' 373 | OutWordDsp(DSP_IsaSlaveControl, MKWORD(rSlaveControl)); | ^~~~~~ drivers/char/mwave/3780i.c:358:31: note: while referencing 'rSlaveControl' 358 | DSP_ISA_SLAVE_CONTROL rSlaveControl; | ^~~~~~~~~~~~~ Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211203084206.3104326-1-keescook@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27misc: at25: Make driver OF independent againAndy Shevchenko1-7/+6
[ Upstream commit 5b557298d7d09cce04e0565a535fbca63661724a ] The commit f60e7074902a ("misc: at25: Make use of device property API") made a good job by enabling the driver for non-OF platforms, but the recent commit 604288bc6196 ("nvmem: eeprom: at25: fix type compiler warnings") brought that back. Restore greatness of the driver once again. Fixes: eab61fb1cc2e ("nvmem: eeprom: at25: fram discovery simplification") Fixes: fd307a4ad332 ("nvmem: prepare basics for FRAM support") Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20211125212729.86585-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/rtrs-clt: Fix the initial value of min_latencyJack Wang1-1/+1
[ Upstream commit 925cac6358677d3d64f9b25f205eeb3d31c9f7f8 ] The type of min_latency is ktime_t, so use KTIME_MAX to initialize the initial value. Fixes: dc3b66a0ce70 ("RDMA/rtrs-clt: Add a minimum latency multipath policy") Link: https://lore.kernel.org/r/20211124081040.19533-1-jinpu.wang@ionos.com Signed-off-by: Jack Wang <jinpu.wang@ionos.com> Reviewed-by: Guoqing Jiang <Guoqing.Jiang@linux.dev> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27clk: imx8mn: Fix imx8mn_clko1_selsAdam Ford1-3/+3
[ Upstream commit 570727e9acfac1c2330a01dd5e1272e9c3acec08 ] When attempting to use sys_pll1_80m as the parent for clko1, the system hangs. This is due to the fact that the source select for sys_pll1_80m was incorrectly pointing to m7_alt_pll_clk, which doesn't yet exist. According to Rev 3 of the TRM, The imx8mn_clko1_sels also incorrectly references an osc_27m which does not exist, nor does an entry for source select bits 010b. Fix both by inserting a dummy clock into the missing space in the table and renaming the incorrectly name clock with dummy. Fixes: 96d6392b54db ("clk: imx: Add support for i.MX8MN clock driver") Signed-off-by: Adam Ford <aford173@gmail.com> Reviewed-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20211117133202.775633-1-aford173@gmail.com Signed-off-by: Abel Vesa <abel.vesa@nxp.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27clk: renesas: rzg2l: propagate return value of_genpd_add_provider_simple()Lad Prabhakar1-2/+1
[ Upstream commit 33748744f15a110a233b6ae0380f476006e770f0 ] of_genpd_add_provider_simple() might fail, this patch makes sure we check the return value of of_genpd_add_provider_simple() by propagating the return value to the caller of rzg2l_cpg_add_clk_domain(). Fixes: ef3c613ccd68a ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20211117115101.28281-3-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27clk: renesas: rzg2l: Check return value of pm_genpd_init()Lad Prabhakar1-1/+13
[ Upstream commit 27527a3d3b162e4512798c058c0e8a216c721187 ] Make sure we check the return value of pm_genpd_init() which might fail. Also add a devres action to remove the power-domain in-case the probe callback fails further down in the code flow. Fixes: ef3c613ccd68a ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC") Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://lore.kernel.org/r/20211117115101.28281-2-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27scsi: pm80xx: Update WARN_ON check in pm8001_mpi_build_cmd()Igor Pylypiv1-1/+3
[ Upstream commit 606c54ae975ad3af540b505b46b55a687501711f ] Starting from commit 05c6c029a44d ("scsi: pm80xx: Increase number of supported queues") driver initializes only max_q_num queues. Do not use an invalid queue if the WARN_ON condition is true. Link: https://lore.kernel.org/r/20211101232825.2350233-4-ipylypiv@google.com Fixes: 7640e1eb8c5d ("scsi: pm80xx: Make mpi_build_cmd locking consistent") Reviewed-by: Vishakha Channapattan <vishakhavc@google.com> Acked-by: Jack Wang <jinpu.wang@ionos.com> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/hns: Validate the pkey indexKamal Heib1-0/+3
[ Upstream commit 2a67fcfa0db6b4075515bd23497750849b88850f ] Before query pkey, make sure that the queried index is valid. Fixes: 9a4435375cd1 ("IB/hns: Add driver files for hns RoCE driver") Link: https://lore.kernel.org/r/20211117145954.123893-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib <kamalheib1@gmail.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27RDMA/bnxt_re: Scan the whole bitmap when checking if "disabling RCFW with ↵Christophe JAILLET2-5/+2
pending cmd-bit" [ Upstream commit a917dfb66c0a1fa1caacf3d71edcafcab48e6ff0 ] The 'cmdq->cmdq_bitmap' bitmap is 'rcfw->cmdq_depth' bits long. The size stored in 'cmdq->bmap_size' is the size of the bitmap in bytes. Remove this erroneous 'bmap_size' and use 'rcfw->cmdq_depth' directly in 'bnxt_qplib_disable_rcfw_channel()'. Otherwise some error messages may be missing. Other uses of 'cmdq_bitmap' already take into account 'rcfw->cmdq_depth' directly. Fixes: 1ac5a4047975 ("RDMA/bnxt_re: Add bnxt_re RoCE driver") Link: https://lore.kernel.org/r/47ed717c3070a1d0f53e7b4c768a4fd11caf365d.1636707421.git.christophe.jaillet@wanadoo.fr Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Acked-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27net: mcs7830: handle usb read errors properlyPavel Skripkin1-2/+10
[ Upstream commit d668769eb9c52b150753f1653f7f5a0aeb8239d2 ] Syzbot reported uninit value in mcs7830_bind(). The problem was in missing validation check for bytes read via usbnet_read_cmd(). usbnet_read_cmd() internally calls usb_control_msg(), that returns number of bytes read. Code should validate that requested number of bytes was actually read. So, this patch adds missing size validation check inside mcs7830_get_reg() to prevent uninit value bugs Reported-and-tested-by: syzbot+003c0a286b9af5412510@syzkaller.appspotmail.com Fixes: 2a36d7083438 ("USB: driver for mcs7830 (aka DeLOCK) USB ethernet adapter") Signed-off-by: Pavel Skripkin <paskripkin@gmail.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20220106225716.7425-1-paskripkin@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27bnxt_en: use firmware provided max timeout for messagesEdwin Peer6-12/+15
[ Upstream commit bce9a0b7900836df223ab638090df0cb8430d9e8 ] Some older devices cannot accommodate the 40 seconds timeout cap for long running commands (such as NVRAM commands) due to hardware limitations. Allow these devices to request more time for these long running commands, but print a warning, since the longer timeout may cause the hung task watchdog to trigger. In the case of a firmware update operation, this is preferable to failing outright. v2: Use bp->hwrm_cmd_max_timeout directly without the constants. Fixes: 881d8353b05e ("bnxt_en: Add an upper bound for all firmware command timeouts.") Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27bnxt_en: move coredump functions into dedicated fileEdwin Peer5-400/+424
[ Upstream commit b032228e58ea2477955058ad4d70a636ce1dec51 ] Change bnxt_get_coredump() and bnxt_get_coredump_length() to non-static functions. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27bnxt_en: Refactor coredump functionsEdwin Peer1-17/+31
[ Upstream commit 9a575c8c25ae2372112db6d6b3e553cd90e9f02b ] The coredump functionality will be used by devlink health. Refactor these functions that get coredump and coredump length. There is no functional change, but the following checkpatch warnings were addressed: - strscpy is preferred over strlcpy. - sscanf results should be checked, with an additional warning. Signed-off-by: Edwin Peer <edwin.peer@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27iwlwifi: mvm: Use div_s64 instead of do_div in iwl_mvm_ftm_rtt_smoothing()Nathan Chancellor1-2/+1
[ Upstream commit 4ccdcc8ffd955490feec05380223db6a48961eb5 ] When building ARCH=arm allmodconfig: drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c: In function ‘iwl_mvm_ftm_rtt_smoothing’: ./include/asm-generic/div64.h:222:35: error: comparison of distinct pointer types lacks a cast [-Werror] 222 | (void)(((typeof((n)) *)0) == ((uint64_t *)0)); \ | ^~ drivers/net/wireless/intel/iwlwifi/mvm/ftm-initiator.c:1070:9: note: in expansion of macro ‘do_div’ 1070 | do_div(rtt_avg, 100); | ^~~~~~ do_div() has to be used with an unsigned 64-bit integer dividend but rtt_avg is a signed 64-bit integer. div_s64() expects a signed 64-bit integer dividend and signed 32-bit divisor, which fits this scenario, so use that function here to fix the warning. Fixes: 8b0f92549f2c ("iwlwifi: mvm: fix 32-bit build in FTM") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20211227191757.2354329-1-nathan@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27pcmcia: fix setting of kthread task statesDominik Brodowski1-5/+3
[ Upstream commit fbb3485f1f931102d8ba606f1c28123f5b48afa3 ] We need to set TASK_INTERRUPTIBLE before calling kthread_should_stop(). Otherwise, kthread_stop() might see that the pccardd thread is still in TASK_RUNNING state and fail to wake it up. Additionally, we only need to set the state back to TASK_RUNNING if kthread_should_stop() breaks the loop. Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reported-by: Al Viro <viro@ZenIV.linux.org.uk> Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Fixes: d3046ba809ce ("pcmcia: fix a boot time warning in pcmcia cs code") Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27can: rcar_canfd: rcar_canfd_channel_probe(): make sure we free CAN network ↵Lad Prabhakar1-3/+2
device [ Upstream commit 72b1e360572f9fa7d08ee554f1da29abce23f288 ] Make sure we free CAN network device in the error path. There are several jumps to fail label after allocating the CAN network device successfully. This patch places the free_candev() under fail label so that in failure path a jump to fail label frees the CAN network device. Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Link: https://lore.kernel.org/all/20220106114801.20563-1-prabhakar.mahadev-lad.rj@bp.renesas.com Reported-by: Pavel Machek <pavel@denx.de> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27can: xilinx_can: xcan_probe(): check for error irqJiasheng Jiang1-1/+6
[ Upstream commit c6564c13dae25cd7f8e1de5127b4da4500ee5844 ] For the possible failure of the platform_get_irq(), the returned irq could be error number and will finally cause the failure of the request_irq(). Consider that platform_get_irq() can now in certain cases return -EPROBE_DEFER, and the consequences of letting request_irq() effectively convert that into -EINVAL, even at probe time rather than later on. So it might be better to check just now. Fixes: b1201e44f50b ("can: xilinx CAN controller support") Link: https://lore.kernel.org/all/20211224021324.1447494-1-jiasheng@iscas.ac.cn Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27can: softing: softing_startstop(): fix set but not used variable warningMarc Kleine-Budde1-5/+6
[ Upstream commit 370d988cc529598ebaec6487d4f84c2115dc696b ] In the function softing_startstop() the variable error_reporting is assigned but not used. The code that uses this variable is commented out. Its stated that the functionality is not finally verified. To fix the warning: | drivers/net/can/softing/softing_fw.c:424:9: error: variable 'error_reporting' set but not used [-Werror,-Wunused-but-set-variable] remove the comment, activate the code, but add a "0 &&" to the if expression and rely on the optimizer rather than the preprocessor to remove the code. Link: https://lore.kernel.org/all/20220109103126.1872833-1-mkl@pengutronix.de Fixes: 03fd3cf5a179 ("can: add driver for Softing card") Cc: Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27tpm_tis: Fix an error handling path in 'tpm_tis_core_init()'Christophe Jaillet1-1/+1
[ Upstream commit e96d52822f5ac0a25de78f95cd23421bcbc93584 ] Commit 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") has moved some code around without updating the error handling path. This is now pointless to 'goto out_err' when neither 'clk_enable()' nor 'ioremap()' have been called yet. Make a direct return instead to avoid undoing things that have not been done. Fixes: 79ca6f74dae0 ("tpm: fix Atmel TPM crash caused by too frequent queries") Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2022-01-27tpm: add request_locality before write TPM_INT_ENABLEChen Jun1-0/+8
[ Upstream commit 0ef333f5ba7f24f5d8478425c163d3097f1c7afd ] Locality is not appropriately requested before writing the int mask. Add the missing boilerplate. Fixes: e6aef069b6e9 ("tpm_tis: convert to using locality callbacks") Signed-off-by: Chen Jun <chenjun102@huawei.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-28 07:16:44 +0300