summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2021-09-22drm/amdgpu: Fix amdgpu_ras_eeprom_init()Luben Tuikov
[ Upstream commit dce4400e6516d18313d23de45b5be8a18980b00e ] No need to account for the 2 bytes of EEPROM address--this is now well abstracted away by the fixes the the lower layers. Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Acked-by: Alexander Deucher <Alexander.Deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22clk: at91: clk-generated: Limit the requested rate to our rangeCodrin Ciubotariu
[ Upstream commit af7651e67b9d5f7e63ea23b118e3672ac662244a ] On clk_generated_determine_rate(), the requested rate could be outside of clk's range. Limit the rate to the clock's range to not return an error. Fixes: df70aeef6083 ("clk: at91: add generated clock driver") Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lore.kernel.org/r/20210707131213.3283509-1-codrin.ciubotariu@microchip.com Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22clk: at91: clk-generated: pass the id of changeable parent at registrationClaudiu Beznea
[ Upstream commit 64c9247b9e87e96e41cea545eb64727cee10c55c ] Pass the ID of changeable parent at registration. This will allow the scalability of this clock driver with regards to the changeable parent ID for versions of this IP where changeable parent is not the last one in the parents list (e.g. SAMA7G5). With this the clock flags are set to zero in case we have no changeable parent. Also in clk_generated_best_diff() the *best_diff variable is check against tmp_diff variable using ">=" operator instead of ">" so that in case the requested frequency could be obtained using fix parents + gck dividers but the clock also supports changeable parent to be able to force the usage of the changeable parent. Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/1595403506-8209-11-git-send-email-claudiu.beznea@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22clk: at91: sam9x60: Don't use audio PLLCodrin Ciubotariu
[ Upstream commit 5bf7f4a249387a6062b9a14c8a77e7ba2fd6a53b ] On sam9x60, there is not audio PLL and so I2S and classD have to use one of the best matching parents for their generated clock. Fixes: 01e2113de9a5 ("clk: at91: add sam9x60 pmc driver") Signed-off-by: Codrin Ciubotariu <codrin.ciubotariu@microchip.com> Link: https://lkml.kernel.org/r/20200131115816.12483-1-codrin.ciubotariu@microchip.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22platform/x86: dell-smbios-wmi: Add missing kfree in error-exit from ↵Hans de Goede
run_smbios_call [ Upstream commit 0487d4fc42d7f31a56cfd9e2237f9ebd889e6112 ] As pointed out be Kees Cook if we return -EIO because the obj->type != ACPI_TYPE_BUFFER, then we must kfree the output buffer before the return. Fixes: 1a258e670434 ("platform/x86: dell-smbios-wmi: Add new WMI dispatcher driver") Reported-by: Kees Cook <keescook@chromium.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20210826140822.71198-1-hdegoede@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22HID: i2c-hid: Fix Elan touchpad regressionJim Broadus
[ Upstream commit 786537063bbfb3a7ebc6fc21b2baf37fb91df401 ] A quirk was recently added for Elan devices that has same device match as an entry earlier in the list. The i2c_hid_lookup_quirk function will always return the last match in the list, so the new entry shadows the old entry. The quirk in the previous entry, I2C_HID_QUIRK_BOGUS_IRQ, silenced a flood of messages which have reappeared in the 5.13 kernel. This change moves the two quirk flags into the same entry. Fixes: ca66a6770bd9 (HID: i2c-hid: Skip ELAN power-on command after reset) Signed-off-by: Jim Broadus <jbroadus@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22scsi: target: avoid per-loop XCOPY buffer allocationsDavid Disseldorp
[ Upstream commit 0ad08996da05b6b735d4963dceab7d2a4043607c ] The main target_xcopy_do_work() loop unnecessarily allocates an I/O buffer with each synchronous READ / WRITE pair. This commit significantly reduces allocations by reusing the XCOPY I/O buffer when possible. Link: https://lore.kernel.org/r/20200327141954.955-4-ddiss@suse.de Reviewed-by: Christoph Hellwig <hch@lst.de> Signed-off-by: David Disseldorp <ddiss@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22scsi: qedf: Fix error codes in qedf_alloc_global_queues()Dan Carpenter
[ Upstream commit ccc89737aa6b9f248cf1623014038beb6c2b7f56 ] This driver has some left over "return 1" on failure style code mixed with "return negative error codes" style code. The caller doesn't care so we should just convert everything to return negative error codes. Then there was a problem that there were two variables used to store error codes which just resulted in confusion. If qedf_alloc_bdq() returned a negative error code, we accidentally returned success instead of propagating the error code. So get rid of the "rc" variable and use "status" every where. Also remove the "status = 0" initialization so that these sorts of bugs will be detected by the compiler in the future. Link: https://lore.kernel.org/r/20210810085023.GA23998@kili Fixes: 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework.") Acked-by: Manish Rangankar <mrangankar@marvell.com> 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>
2021-09-22scsi: qedi: Fix error codes in qedi_alloc_global_queues()Dan Carpenter
[ Upstream commit 4dbe57d46d54a847875fa33e7d05877bb341585e ] This function had some left over code that returned 1 on error instead negative error codes. Convert everything to use negative error codes. The caller treats all non-zero returns the same so this does not affect run time. A couple places set "rc" instead of "status" so those error paths ended up returning success by mistake. Get rid of the "rc" variable and use "status" everywhere. Remove the bogus "status = 0" initialization, as a future proofing measure so the compiler will warn about uninitialized error codes. Link: https://lore.kernel.org/r/20210810084753.GD23810@kili Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar <mrangankar@marvell.com> 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>
2021-09-22scsi: smartpqi: Fix an error code in pqi_get_raid_map()Dan Carpenter
[ Upstream commit d1f6581a6796c4e9fd8a4a24e8b77463d18f0df1 ] Return -EINVAL on failure instead of success. Link: https://lore.kernel.org/r/20210810084613.GB23810@kili Fixes: a91aaae0243b ("scsi: smartpqi: allow for larger raid maps") 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>
2021-09-22pinctrl: single: Fix error return code in pcs_parse_bits_in_pinctrl_entry()Zhen Lei
[ Upstream commit d789a490d32fdf0465275e3607f8a3bc87d3f3ba ] Fix to return -ENOTSUPP instead of 0 when PCS_HAS_PINCONF is true, which is the same as that returned in pcs_parse_pinconf(). Fixes: 4e7e8017a80e ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com> Link: https://lore.kernel.org/r/20210722033930.4034-2-thunder.leizhen@huawei.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22scsi: fdomain: Fix error return code in fdomain_probe()Wei Li
[ Upstream commit 632c4ae6da1d629eddf9da1e692d7617c568c256 ] If request_region() fails the return value is not set. Return -EBUSY on error. Link: https://lore.kernel.org/r/20210715032625.1395495-1-liwei391@huawei.com Fixes: 8674a8aa2c39 ("scsi: fdomain: Add PCMCIA support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Li <liwei391@huawei.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22RDMA/efa: Remove double QP type assignmentLeon Romanovsky
[ Upstream commit f9193d266347fe9bed5c173e7a1bf96268142a79 ] The QP type is set by the IB/core and shouldn't be set in the driver. Fixes: 40909f664d27 ("RDMA/efa: Add EFA verbs implementation") Link: https://lore.kernel.org/r/838c40134c1590167b888ca06ad51071139ff2ae.1627040189.git.leonro@nvidia.com Acked-by: Gal Pressman <galpress@amazon.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>
2021-09-22vfio: Use config not menuconfig for VFIO_NOIOMMUJason Gunthorpe
[ Upstream commit 26c22cfde5dd6e63f25c48458b0185dcb0fbb2fd ] VFIO_NOIOMMU is supposed to be an element in the VFIO menu, not start a new menu. Correct this copy-paste mistake. Fixes: 03a76b60f8ba ("vfio: Include No-IOMMU mode") Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Link: https://lore.kernel.org/r/0-v1-3f0b685c3679+478-vfio_menuconfig_jgg@nvidia.com Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22pinctrl: samsung: Fix pinctrl bank pin countJaehyoung Choi
[ Upstream commit 70115558ab02fe8d28a6634350b3491a542aaa02 ] Commit 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") changes the order of GPIO and pinctrl registration: now pinctrl is registered before GPIO. That means gpio_chip->ngpio is not set when samsung_pinctrl_register() called, and one cannot rely on that value anymore. Use `pin_bank->nr_pins' instead of `pin_bank->gpio_chip.ngpio' to fix mentioned inconsistency. Fixes: 1abd18d1a51a ("pinctrl: samsung: Register pinctrl before GPIO") Signed-off-by: Jaehyoung Choi <jkkkkk.choi@samsung.com> Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org> Link: https://lore.kernel.org/r/20210730192905.7173-1-semen.protsenko@linaro.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22RDMA/iwcm: Release resources if iw_cm module initialization failsLeon Romanovsky
[ Upstream commit e677b72a0647249370f2635862bf0241c86f66ad ] The failure during iw_cm module initialization partially left the system with unreleased memory and other resources. Rewrite the module init/exit routines in such way that netlink commands will be opened only after successful initialization. Fixes: b493d91d333e ("iwcm: common code for port mapper") Link: https://lore.kernel.org/r/b01239f99cb1a3e6d2b0694c242d89e6410bcd93.1627048781.git.leonro@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>
2021-09-22IB/hfi1: Adjust pkey entry in index 0Mike Marciniszyn
[ Upstream commit 62004871e1fa7f9a60797595c03477af5b5ec36f ] It is possible for the primary IPoIB network device associated with any RDMA device to fail to join certain multicast groups preventing IPv6 neighbor discovery and possibly other network ULPs from working correctly. The IPv4 broadcast group is not affected as the IPoIB network device handles joining that multicast group directly. This is because the primary IPoIB network device uses the pkey at ndex 0 in the associated RDMA device's pkey table. Anytime the pkey value of index 0 changes, the primary IPoIB network device automatically modifies it's broadcast address (i.e. /sys/class/net/[ib0]/broadcast), since the broadcast address includes the pkey value, and then bounces carrier. This includes initial pkey assignment, such as when the pkey at index 0 transitions from the opa default of invalid (0x0000) to some value such as the OPA default pkey for Virtual Fabric 0: 0x8001 or when the fabric manager is restarted with a configuration change causing the pkey at index 0 to change. Many network ULPs are not sensitive to the carrier bounce and are not expecting the broadcast address to change including the linux IPv6 stack. This problem does not affect IPoIB child network devices as their pkey value is constant for all time. To mitigate this issue, change the default pkey in at index 0 to 0x8001 to cover the predominant case and avoid issues as ipoib comes up and the FM sweeps. At some point, ipoib multicast support should automatically fix non-broadcast addresses as it does with the primary broadcast address. Fixes: 7724105686e7 ("IB/hfi1: add driver files") Link: https://lore.kernel.org/r/20210715160445.142451.47651.stgit@awfm-01.cornelisnetworks.com Suggested-by: Josh Collier <josh.d.collier@intel.com> Signed-off-by: Mike Marciniszyn <mike.marciniszyn@cornelisnetworks.com> Signed-off-by: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22HID: input: do not report stylus battery state as "full"Dmitry Torokhov
[ Upstream commit f4abaa9eebde334045ed6ac4e564d050f1df3013 ] The power supply states of discharging, charging, full, etc, represent state of charging, not the capacity level of the battery (for which we have a separate property). Current HID usage tables to not allow for expressing charging state of the batteries found in generic styli, so we should simply assume that the battery is discharging even if current capacity is at 100% when battery strength reporting is done via HID interface. In fact, we were doing just that before commit 581c4484769e. This change helps UIs to not mis-represent fully charged batteries in styli as being charging/topping-off. Fixes: 581c4484769e ("HID: input: map digitizer battery usage") Reported-by: Kenneth Albanowski <kenalba@google.com> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22PCI: aardvark: Fix masking and unmasking legacy INTx interruptsPali Rohár
commit d212dcee27c1f89517181047e5485fcbba4a25c2 upstream. irq_mask and irq_unmask callbacks need to be properly guarded by raw spin locks as masking/unmasking procedure needs atomic read-modify-write operation on hardware register. Link: https://lore.kernel.org/r/20210820155020.3000-1-pali@kernel.org Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI: aardvark: Increase polling delay to 1.5s while waiting for PIO responsePali Rohár
commit 02bcec3ea5591720114f586960490b04b093a09e upstream. Measurements in different conditions showed that aardvark hardware PIO response can take up to 1.44s. Increase wait timeout from 1ms to 1.5s to ensure that we do not miss responses from hardware. After 1.44s hardware returns errors (e.g. Completer abort). The previous two patches fixed checking for PIO status, so now we can use it to also catch errors which are reported by hardware after 1.44s. After applying this patch, kernel can detect and print PIO errors to dmesg: [ 6.879999] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100004 [ 6.896436] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 [ 6.913049] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100010 [ 6.929663] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100010 [ 6.953558] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100014 [ 6.970170] advk-pcie d0070000.pcie: Non-posted PIO Response Status: CA, 0xe00 @ 0x100014 [ 6.994328] advk-pcie d0070000.pcie: Posted PIO Response Status: COMP_ERR, 0x804 @ 0x100004 Without this patch kernel prints only a generic error to dmesg: [ 5.246847] advk-pcie d0070000.pcie: config read/write timed out Link: https://lore.kernel.org/r/20210722144041.12661-3-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org # 7fbcb5da811b ("PCI: aardvark: Don't rely on jiffies while holding spinlock") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI: aardvark: Fix checking for PIO statusEvan Wang
commit fcb461e2bc8b83b7eaca20cb2221e8b940f2189c upstream. There is an issue that when PCIe switch is connected to an Armada 3700 board, there will be lots of warnings about PIO errors when reading the config space. According to Aardvark PIO read and write sequence in HW specification, the current way to check PIO status has the following issues: 1) For PIO read operation, it reports the error message, which should be avoided according to HW specification. 2) For PIO read and write operations, it only checks PIO operation complete status, which is not enough, and error status should also be checked. This patch aligns the code with Aardvark PIO read and write sequence in HW specification on PIO status check and fix the warnings when reading config space. [pali: Fix CRS handling when CRSSVE is not enabled] Link: https://lore.kernel.org/r/20210722144041.12661-2-pali@kernel.org Tested-by: Victor Gu <xigu@marvell.com> Signed-off-by: Evan Wang <xswang@marvell.com> Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Victor Gu <xigu@marvell.com> Reviewed-by: Marek Behún <kabel@kernel.org> Cc: stable@vger.kernel.org # b1bd5714472c ("PCI: aardvark: Indicate error in 'val' when config read fails") Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI: xilinx-nwl: Enable the clock through CCFHyun Kwon
commit de0a01f5296651d3a539f2d23d0db8f359483696 upstream. Enable PCIe reference clock. There is no remove function that's why this should be enough for simple operation. Normally this clock is enabled by default by firmware but there are usecases where this clock should be enabled by driver itself. It is also good that PCIe clock is recorded in a clock framework. Link: https://lore.kernel.org/r/ee6997a08fab582b1c6de05f8be184f3fe8d5357.1624618100.git.michal.simek@xilinx.com Fixes: ab597d35ef11 ("PCI: xilinx-nwl: Add support for Xilinx NWL PCIe Host Controller") Signed-off-by: Hyun Kwon <hyun.kwon@xilinx.com> Signed-off-by: Bharat Kumar Gogada <bharat.kumar.gogada@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI: Return ~0 data on pciconfig_read() CAP_SYS_ADMIN failureKrzysztof Wilczyński
commit a8bd29bd49c4156ea0ec5a97812333e2aeef44e7 upstream. The pciconfig_read() syscall reads PCI configuration space using hardware-dependent config accessors. If the read fails on PCI, most accessors don't return an error; they pretend the read was successful and got ~0 data from the device, so the syscall returns success with ~0 data in the buffer. When the accessor does return an error, pciconfig_read() normally fills the user's buffer with ~0 and returns an error in errno. But after e4585da22ad0 ("pci syscall.c: Switch to refcounting API"), we don't fill the buffer with ~0 for the EPERM "user lacks CAP_SYS_ADMIN" error. Userspace may rely on the ~0 data to detect errors, but after e4585da22ad0, that would not detect CAP_SYS_ADMIN errors. Restore the original behaviour of filling the buffer with ~0 when the CAP_SYS_ADMIN check fails. [bhelgaas: commit log, fold in Nathan's fix https://lore.kernel.org/r/20210803200836.500658-1-nathan@kernel.org] Fixes: e4585da22ad0 ("pci syscall.c: Switch to refcounting API") Link: https://lore.kernel.org/r/20210729233755.1509616-1-kw@linux.com Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI: Restrict ASMedia ASM1062 SATA Max Payload Size SupportedMarek Behún
commit b12d93e9958e028856cbcb061b6e64728ca07755 upstream. The ASMedia ASM1062 SATA controller advertises Max_Payload_Size_Supported of 512, but in fact it cannot handle incoming TLPs with payload size of 512. We discovered this issue on PCIe controllers capable of MPS = 512 (Aardvark and DesignWare), where the issue presents itself as an External Abort. Bjorn Helgaas says: Probably ASM1062 reports a Malformed TLP error when it receives a data payload of 512 bytes, and Aardvark, DesignWare, etc convert this to an arm64 External Abort. [1] To avoid this problem, limit the ASM1062 Max Payload Size Supported to 256 bytes, so we set the Max Payload Size of devices that may send TLPs to the ASM1062 to 256 or less. [1] https://lore.kernel.org/linux-pci/20210601170907.GA1949035@bjorn-Precision-5520/ BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=212695 Link: https://lore.kernel.org/r/20210624171418.27194-2-kabel@kernel.org Reported-by: Rötti <espressobinboardarmbiantempmailaddress@posteo.de> Signed-off-by: Marek Behún <kabel@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> Reviewed-by: Pali Rohár <pali@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI/portdrv: Enable Bandwidth Notification only if port supports itStuart Hayes
commit 00823dcbdd415c868390feaca16f0265101efab4 upstream. Previously we assumed that all Root Ports and Switch Downstream Ports supported Link Bandwidth Notification. Per spec, this is only required for Ports supporting Links wider than x1 and/or multiple Link speeds (PCIe r5.0, sec 7.5.3.6). Because we assumed all Ports supported it, we tried to set up a Bandwidth Notification IRQ, which failed for devices that don't support IRQs at all, which meant pcieport didn't attach to the Port at all. Check the Link Bandwidth Notification Capability bit and enable the service only when the Port supports it. [bhelgaas: commit log] Fixes: e8303bb7a75c ("PCI/LINK: Report degraded links via link bandwidth notification") Link: https://lore.kernel.org/r/20210512213314.7778-1-stuart.w.hayes@gmail.com Signed-off-by: Stuart Hayes <stuart.w.hayes@gmail.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Lukas Wunner <lukas@wunner.de> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22libata: add ATA_HORKAGE_NO_NCQ_TRIM for Samsung 860 and 870 SSDsHans de Goede
commit 8a6430ab9c9c87cb64c512e505e8690bbaee190b upstream. Commit ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") limited the existing ATA_HORKAGE_NO_NCQ_TRIM quirk from "Samsung SSD 8*", covering all Samsung 800 series SSDs, to only apply to "Samsung SSD 840*" and "Samsung SSD 850*" series based on information from Samsung. But there is a large number of users which is still reporting issues with the Samsung 860 and 870 SSDs combined with Intel, ASmedia or Marvell SATA controllers and all reporters also report these problems going away when disabling queued trims. Note that with AMD SATA controllers users are reporting even worse issues and only completely disabling NCQ helps there, this will be addressed in a separate patch. Fixes: ca6bfcb2f6d9 ("libata: Enable queued TRIM for Samsung SSD 860") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=203475 Cc: stable@vger.kernel.org Cc: Kate Hsuan <hpa@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Damien Le Moal <damien.lemoal@wdc.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Link: https://lore.kernel.org/r/20210823095220.30157-1-hdegoede@redhat.com Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22dmaengine: imx-sdma: remove duplicated sdma_load_contextRobin Gong
commit e555a03b112838883fdd8185d613c35d043732f2 upstream. Since sdma_transfer_init() will do sdma_load_context before any sdma transfer, no need once more in sdma_config_channel(). Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") Cc: <stable@vger.kernel.org> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Acked-by: Vinod Koul <vkoul@kernel.org> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22Revert "dmaengine: imx-sdma: refine to load context only once"Robin Gong
commit 8592f02464d52776c5cfae4627c6413b0ae7602d upstream. This reverts commit ad0d92d7ba6aecbe2705907c38ff8d8be4da1e9c, because in spi-imx case, burst length may be changed dynamically. Fixes: ad0d92d7ba6a ("dmaengine: imx-sdma: refine to load context only once") Cc: <stable@vger.kernel.org> Signed-off-by: Robin Gong <yibin.gong@nxp.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Richard Leitner <richard.leitner@skidata.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22media: rc-loopback: return number of emitters rather than errorSean Young
commit 6b7f554be8c92319d7e6df92fd247ebb9beb4a45 upstream. The LIRC_SET_TRANSMITTER_MASK ioctl should return the number of emitters if an invalid list was set. Cc: stable@vger.kernel.org Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22media: uvc: don't do DMA on stackMauro Carvalho Chehab
commit 1a10d7fdb6d0e235e9d230916244cc2769d3f170 upstream. As warned by smatch: drivers/media/usb/uvc/uvc_v4l2.c:911 uvc_ioctl_g_input() error: doing dma on the stack (&i) drivers/media/usb/uvc/uvc_v4l2.c:943 uvc_ioctl_s_input() error: doing dma on the stack (&i) those two functions call uvc_query_ctrl passing a pointer to a data at the DMA stack. those are used to send URBs via usb_control_msg(). Using DMA stack is not supported and should not work anymore on modern Linux versions. So, use a kmalloc'ed buffer. Cc: stable@vger.kernel.org # Kernel 4.9 and upper Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22VMCI: fix NULL pointer dereference when unmapping queue pairWang Hai
commit a30dc6cf0dc51419021550152e435736aaef8799 upstream. I got a NULL pointer dereference report when doing fuzz test: Call Trace: qp_release_pages+0xae/0x130 qp_host_unregister_user_memory.isra.25+0x2d/0x80 vmci_qp_broker_unmap+0x191/0x320 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 vmci_host_unlocked_ioctl+0x59f/0xd50 ? do_vfs_ioctl+0x14b/0xa10 ? tomoyo_file_ioctl+0x28/0x30 ? vmci_host_do_alloc_queuepair.isra.9+0x1c0/0x1c0 __x64_sys_ioctl+0xea/0x120 do_syscall_64+0x34/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae When a queue pair is created by the following call, it will not register the user memory if the page_store is NULL, and the entry->state will be set to VMCIQPB_CREATED_NO_MEM. vmci_host_unlocked_ioctl vmci_host_do_alloc_queuepair vmci_qp_broker_alloc qp_broker_alloc qp_broker_create // set entry->state = VMCIQPB_CREATED_NO_MEM; When unmapping this queue pair, qp_host_unregister_user_memory() will be called to unregister the non-existent user memory, which will result in a null pointer reference. It will also change VMCIQPB_CREATED_NO_MEM to VMCIQPB_CREATED_MEM, which should not be present in this operation. Only when the qp broker has mem, it can unregister the user memory when unmapping the qp broker. Only when the qp broker has no mem, it can register the user memory when mapping the qp broker. Fixes: 06164d2b72aa ("VMCI: queue pairs implementation.") Cc: stable <stable@vger.kernel.org> Reported-by: Hulk Robot <hulkci@huawei.com> Reviewed-by: Jorgen Hansen <jhansen@vmware.com> Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20210818124845.488312-1-wanghai38@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22dm crypt: Avoid percpu_counter spinlock contention in crypt_page_alloc()Arne Welzel
commit 528b16bfc3ae5f11638e71b3b63a81f9999df727 upstream. On systems with many cores using dm-crypt, heavy spinlock contention in percpu_counter_compare() can be observed when the page allocation limit for a given device is reached or close to be reached. This is due to percpu_counter_compare() taking a spinlock to compute an exact result on potentially many CPUs at the same time. Switch to non-exact comparison of allocated and allowed pages by using the value returned by percpu_counter_read_positive() to avoid taking the percpu_counter spinlock. This may over/under estimate the actual number of allocated pages by at most (batch-1) * num_online_cpus(). Currently, batch is bounded by 32. The system on which this issue was first observed has 256 CPUs and 512GB of RAM. With a 4k page size, this change may over/under estimate by 31MB. With ~10G (2%) allowed dm-crypt allocations, this seems an acceptable error. Certainly preferred over running into the spinlock contention. This behavior was reproduced on an EC2 c5.24xlarge instance with 96 CPUs and 192GB RAM as follows, but can be provoked on systems with less CPUs as well. * Disable swap * Tune vm settings to promote regular writeback $ echo 50 > /proc/sys/vm/dirty_expire_centisecs $ echo 25 > /proc/sys/vm/dirty_writeback_centisecs $ echo $((128 * 1024 * 1024)) > /proc/sys/vm/dirty_background_bytes * Create 8 dmcrypt devices based on files on a tmpfs * Create and mount an ext4 filesystem on each crypt devices * Run stress-ng --hdd 8 within one of above filesystems Total %system usage collected from sysstat goes to ~35%. Write throughput on the underlying loop device is ~2GB/s. perf profiling an individual kworker kcryptd thread shows the following profile, indicating spinlock contention in percpu_counter_compare(): 99.98% 0.00% kworker/u193:46 [kernel.kallsyms] [k] ret_from_fork | --ret_from_fork kthread worker_thread | --99.92%--process_one_work | |--80.52%--kcryptd_crypt | | | |--62.58%--mempool_alloc | | | | | --62.24%--crypt_page_alloc | | | | | --61.51%--__percpu_counter_compare | | | | | --61.34%--__percpu_counter_sum | | | | | |--58.68%--_raw_spin_lock_irqsave | | | | | | | --58.30%--native_queued_spin_lock_slowpath | | | | | --0.69%--cpumask_next | | | | | --0.51%--_find_next_bit | | | |--10.61%--crypt_convert | | | | | |--6.05%--xts_crypt ... After applying this patch and running the same test, %system usage is lowered to ~7% and write throughput on the loop device increases to ~2.7GB/s. perf report shows mempool_alloc() as ~8% rather than ~62% in the profile and not hitting the percpu_counter() spinlock anymore. |--8.15%--mempool_alloc | | | |--3.93%--crypt_page_alloc | | | | | --3.75%--__alloc_pages | | | | | --3.62%--get_page_from_freelist | | | | | --3.22%--rmqueue_bulk | | | | | --2.59%--_raw_spin_lock | | | | | --2.57%--native_queued_spin_lock_slowpath | | | --3.05%--_raw_spin_lock_irqsave | | | --2.49%--native_queued_spin_lock_slowpath Suggested-by: DJ Gregor <dj@corelight.com> Reviewed-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Arne Welzel <arne.welzel@corelight.com> Fixes: 5059353df86e ("dm crypt: limit the number of allocated pages") Cc: stable@vger.kernel.org Signed-off-by: Mike Snitzer <snitzer@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22power: supply: max17042: handle fails of reading status registerKrzysztof Kozlowski
commit 54784ffa5b267f57161eb8fbb811499f22a0a0bf upstream. Reading status register can fail in the interrupt handler. In such case, the regmap_read() will not store anything useful under passed 'val' variable and random stack value will be used to determine type of interrupt. Handle the regmap_read() failure to avoid handling interrupt type and triggering changed power supply event based on random stack value. Fixes: 39e7213edc4f ("max17042_battery: Support regmap to access device's registers") Cc: <stable@vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22soc: aspeed: p2a-ctrl: Fix boundary check for mmapIwona Winiarska
commit 8b07e990fb254fcbaa919616ac77f981cb48c73d upstream. The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one side of the comparison, and uses resource address (rather than just the resource size) on the other side of the comparison. This can allow malicious userspace to easily bypass the boundary check and map pages that are located outside memory-region reserved by the driver. Fixes: 01c60dcea9f7 ("drivers/misc: Add Aspeed P2A control driver") Cc: stable@vger.kernel.org Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22soc: aspeed: lpc-ctrl: Fix boundary check for mmapIwona Winiarska
commit b49a0e69a7b1a68c8d3f64097d06dabb770fec96 upstream. The check mixes pages (vm_pgoff) with bytes (vm_start, vm_end) on one side of the comparison, and uses resource address (rather than just the resource size) on the other side of the comparison. This can allow malicious userspace to easily bypass the boundary check and map pages that are located outside memory-region reserved by the driver. Fixes: 6c4e97678501 ("drivers/misc: Add Aspeed LPC control driver") Cc: stable@vger.kernel.org Signed-off-by: Iwona Winiarska <iwona.winiarska@intel.com> Reviewed-by: Andrew Jeffery <andrew@aj.id.au> Tested-by: Andrew Jeffery <andrew@aj.id.au> Reviewed-by: Joel Stanley <joel@aj.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22soc: qcom: aoss: Fix the out of bound usage of cooling_devsManivannan Sadhasivam
commit a89f355e469dcda129c2522be4fdba00c1c74c83 upstream. In "qmp_cooling_devices_register", the count value is initially QMP_NUM_COOLING_RESOURCES, which is 2. Based on the initial count value, the memory for cooling_devs is allocated. Then while calling the "qmp_cooling_device_add" function, count value is post-incremented for each child node. This makes the out of bound access to the cooling_dev array. Fix it by passing the QMP_NUM_COOLING_RESOURCES definition to devm_kzalloc() and initializing the count to 0. While at it, let's also free the memory allocated to cooling_dev if no cooling device is found in DT and during unroll phase. Cc: stable@vger.kernel.org # 5.4 Fixes: 05589b30b21a ("soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC.") Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210629153249.73428-1-manivannan.sadhasivam@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22pinctrl: ingenic: Fix incorrect pull up/down infoPaul Cercueil
commit d5e931403942b3af39212960c2592b5ba741b2bf upstream. Fix the pull up/down info for both the JZ4760 and JZ4770 SoCs, as the previous values sometimes contradicted what's written in the programming manual. Fixes: b5c23aa46537 ("pinctrl: add a pinctrl driver for the Ingenic jz47xx SoCs") Cc: <stable@vger.kernel.org> # v4.12 Signed-off-by: Paul Cercueil <paul@crapouillou.net> Tested-by: 周琰杰 (Zhou Yanjie)<zhouyanjie@wanyeetech.com> Link: https://lore.kernel.org/r/20210717174836.14776-1-paul@crapouillou.net Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22pinctrl: stmfx: Fix hazardous u8[] to unsigned long castMarc Zyngier
commit 1b73e588f47397dee6e4bdfd953e0306c60b5fe5 upstream. Casting a small array of u8 to an unsigned long is *never* OK: - it does funny thing when the array size is less than that of a long, as it accesses random places in the stack - it makes everything even more fun with a BE kernel Fix this by building the unsigned long used as a bitmap byte by byte, in a way that works across endianess and has no undefined behaviours. An extra BUILD_BUG_ON() catches the unlikely case where the array would be larger than a single unsigned long. Fixes: 1490d9f841b1 ("pinctrl: Add STMFX GPIO expander Pinctrl/GPIO driver") Signed-off-by: Marc Zyngier <maz@kernel.org> Cc: stable@vger.kernel.org Cc: Amelie Delaunay <amelie.delaunay@foss.st.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Alexandre Torgue <alexandre.torgue@foss.st.com> Link: https://lore.kernel.org/r/20210725180830.250218-1-maz@kernel.org Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22PCI/MSI: Skip masking MSI-X on Xen PVMarek Marczykowski-Górecki
commit 1a519dc7a73c977547d8b5108d98c6e769c89f4b upstream. When running as Xen PV guest, masking MSI-X is a responsibility of the hypervisor. The guest has no write access to the relevant BAR at all - when it tries to, it results in a crash like this: BUG: unable to handle page fault for address: ffffc9004069100c #PF: supervisor write access in kernel mode #PF: error_code(0x0003) - permissions violation RIP: e030:__pci_enable_msix_range.part.0+0x26b/0x5f0 e1000e_set_interrupt_capability+0xbf/0xd0 [e1000e] e1000_probe+0x41f/0xdb0 [e1000e] local_pci_probe+0x42/0x80 (...) The recently introduced function msix_mask_all() does not check the global variable pci_msi_ignore_mask which is set by XEN PV to bypass the masking of MSI[-X] interrupts. Add the check to make this function XEN PV compatible. Fixes: 7d5ec3d36123 ("PCI/MSI: Mask all unused MSI-X entries") Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Bjorn Helgaas <bhelgaas@google.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210826170342.135172-1-marmarek@invisiblethingslab.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22rtc: tps65910: Correct driver module aliasDmitry Osipenko
commit 8d448fa0a8bb1c8d94eef7647edffe9ac81a281e upstream. The TPS65910 RTC driver module doesn't auto-load because of the wrong module alias that doesn't match the device name, fix it. Cc: stable@vger.kernel.org Reported-by: Anton Bambura <jenneron@protonmail.com> Tested-by: Anton Bambura <jenneron@protonmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/r/20210808160030.8556-1-digetx@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-16Revert "block: nbd: add sanity check for first_minor"Greg Kroah-Hartman
This reverts commit b3fa499d72a0db612f12645265a36751955c0037 which is commit b1a811633f7321cf1ae2bb76a66805b7720e44c9 upstream. The backport of this is reported to be causing some problems, so revert this for now until they are worked out. Link: https://lore.kernel.org/r/CACPK8XfUWoOHr-0RwRoYoskia4fbAbZ7DYf5wWBnv6qUnGq18w@mail.gmail.com Reported-by: Joel Stanley <joel@jms.id.au> Cc: Christoph Hellwig <hch@lst.de> Cc: Pavel Skripkin <paskripkin@gmail.com> Cc: Jens Axboe <axboe@kernel.dk> Cc: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15clk: kirkwood: Fix a clocking boot regressionLinus Walleij
commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. Since a few kernel releases the Pogoplug 4 has crashed like this during boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 (...) [<c04116ec>] (strlen) from [<c00ead80>] (kstrdup+0x1c/0x4c) [<c00ead80>] (kstrdup) from [<c04591d8>] (__clk_register+0x44/0x37c) [<c04591d8>] (__clk_register) from [<c04595ec>] (clk_hw_register+0x20/0x44) [<c04595ec>] (clk_hw_register) from [<c045bfa8>] (__clk_hw_register_mux+0x198/0x1e4) [<c045bfa8>] (__clk_hw_register_mux) from [<c045c050>] (clk_register_mux_table+0x5c/0x6c) [<c045c050>] (clk_register_mux_table) from [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0) from [<c0aceae0>] (of_clk_init+0x12c/0x214) [<c0aceae0>] (of_clk_init) from [<c0ab576c>] (time_init+0x20/0x2c) [<c0ab576c>] (time_init) from [<c0ab3d18>] (start_kernel+0x3dc/0x56c) [<c0ab3d18>] (start_kernel) from [<00000000>] (0x0) Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) This is because the "powersave" mux clock 0 was provided in an unterminated array, which is required by the loop in the driver: /* Count, allocate, and register clock muxes */ for (n = 0; desc[n].name;) n++; Here n will go out of bounds and then call clk_register_mux() on random memory contents after the mux clock. Fix this by terminating the array with a blank entry. Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") Cc: stable@vger.kernel.org Cc: Andrew Lunn <andrew@lunn.ch> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz> Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15backlight: pwm_bl: Improve bootloader/kernel device handoverDaniel Thompson
commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream. Currently there are (at least) two problems in the way pwm_bl starts managing the enable_gpio pin. Both occur when the backlight is initially off and the driver finds the pin not already in output mode and, as a result, unconditionally switches it to output-mode and asserts the signal. Problem 1: This could cause the backlight to flicker since, at this stage in driver initialisation, we have no idea what the PWM and regulator are doing (an unconfigured PWM could easily "rest" at 100% duty cycle). Problem 2: This will cause us not to correctly honour the post_pwm_on_delay (which also risks flickers). Fix this by moving the code to configure the GPIO output mode until after we have examines the handover state. That allows us to initialize enable_gpio to off if the backlight is currently off and on if the backlight is on. Cc: stable@vger.kernel.org Reported-by: Marek Vasut <marex@denx.de> Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org> Acked-by: Marek Vasut <marex@denx.de> Tested-by: Marek Vasut <marex@denx.de> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15fbmem: don't allow too huge resolutionsTetsuo Handa
commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream. syzbot is reporting page fault at vga16fb_fillrect() [1], for vga16fb_check_var() is failing to detect multiplication overflow. if (vxres * vyres > maxmem) { vyres = maxmem / vxres; if (vyres < yres) return -ENOMEM; } Since no module would accept too huge resolutions where multiplication overflow happens, let's reject in the common path. Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1] Reported-by: syzbot <syzbot+04168c8063cfdde1db5e@syzkaller.appspotmail.com> Debugged-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15tty: Fix data race between tiocsti() and flush_to_ldisc()Nguyen Dinh Phi
commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream. The ops->receive_buf() may be accessed concurrently from these two functions. If the driver flushes data to the line discipline receive_buf() method while tiocsti() is waiting for the ops->receive_buf() to finish its work, the data race will happen. For example: tty_ioctl |tty_ldisc_receive_buf ->tioctsi | ->tty_port_default_receive_buf | ->tty_ldisc_receive_buf ->hci_uart_tty_receive | ->hci_uart_tty_receive ->h4_recv | ->h4_recv In this case, the h4 receive buffer will be overwritten by the latecomer, and we will lost the data. Hence, change tioctsi() function to use the exclusive lock interface from tty_buffer to avoid the data race. Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com Reviewed-by: Jiri Slaby <jirislaby@kernel.org> Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com> Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-15octeontx2-af: Fix loop in free and unmap counterSubbaraya Sundeep
[ Upstream commit 6537e96d743b89294b397b4865c6c061abae31b0 ] When the given counter does not belong to the entry then code ends up in infinite loop because the loop cursor, entry is not getting updated further. This patch fixes that by updating entry for every iteration. Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter") Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15net: qualcomm: fix QCA7000 checksum handlingStefan Wahren
[ Upstream commit 429205da6c834447a57279af128bdd56ccd5225e ] Based on tests the QCA7000 doesn't support checksum offloading. So assume ip_summed is CHECKSUM_NONE and let the kernel take care of the checksum handling. This fixes data transfer issues in noisy environments. Reported-by: Michael Heimpold <michael.heimpold@in-tech.com> Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000") Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15brcmfmac: pcie: fix oops on failure to resume and reprobeAhmad Fatoum
[ Upstream commit d745ca4f2c4ae9f1bd8cf7d8ac6e22d739bffd19 ] When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a hot resume and then fall back to removing the PCI device and then reprobing. If this probe fails, the kernel will oops, because brcmf_err, which is called to report the failure will dereference the stale bus pointer. Open code and use the default bus-less brcmf_err to avoid this. Fixes: 8602e62441ab ("brcmfmac: pass bus to the __brcmf_err() in pcie.c") Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210817063521.22450-1-a.fatoum@pengutronix.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15bcma: Fix memory leak for internally-handled coresZenghui Yu
[ Upstream commit b63aed3ff195130fef12e0af590f4838cf0201d8 ] kmemleak reported that dev_name() of internally-handled cores were leaked on driver unbinding. Let's use device_initialize() to take refcounts for them and put_device() to properly free the related stuff. While looking at it, there's another potential issue for those which should be *registered* into driver core. If device_register() failed, we put device once and freed bcma_device structures. In bcma_unregister_cores(), they're treated as unregistered and we hit both UAF and double-free. That smells not good and has also been fixed now. Fixes: ab54bc8460b5 ("bcma: fill core details for every device") Signed-off-by: Zenghui Yu <yuzenghui@huawei.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210727025232.663-2-yuzenghui@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-15ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point()Dan Carpenter
[ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ] This error path is unlikely because of it checked for NULL and returned -ENOMEM earlier in the function. But it should return an error code here as well if we ever do hit it because of a race condition or something. Fixes: bdcd81707973 ("Add ath6kl cleaned up driver") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Kalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210813113438.GB30697@kili Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.0.4) at 2024-09-16 20:38:14 +0000