summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-07-20watchdog: aspeed: fix hardware timeout calculationTao Ren1-1/+1
[ Upstream commit e7dc481c92060f9ce872878b0b7a08c24713a7e5 ] Fix hardware timeout calculation in aspeed_wdt_set_timeout function to ensure the reload value does not exceed the hardware limit. Fixes: efa859f7d786 ("watchdog: Add Aspeed watchdog driver") Reported-by: Amithash Prasad <amithash@fb.com> Signed-off-by: Tao Ren <rentao.bupt@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20210417034249.5978-1-rentao.bupt@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20misc: alcor_pci: fix inverted branch conditionTong Zhang1-1/+1
commit 281e468446994a7672733af2bf941f4110d4a895 upstream. This patch fixes a trivial mistake that I made in the previous attempt in fixing the null bridge issue. The branch condition is inverted and we should call alcor_pci_find_cap_offset() only if bridge is not null. Reported-by: Colin Ian King <colin.king@canonical.com> Fixes: 3ce3e45cc333 ("misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge") Signed-off-by: Tong Zhang <ztong0001@gmail.com> Link: https://lore.kernel.org/r/20210522043725.602179-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-07-20power: supply: rt5033_battery: Fix device tree enumerationStephan Gerhold2-1/+9
[ Upstream commit f3076cd8d1d5fa64b5e1fa5affc045c2fc123baa ] The fuel gauge in the RT5033 PMIC has its own I2C bus and interrupt line. Therefore, it is not actually part of the RT5033 MFD and needs its own of_match_table to probe properly. Also, given that it's independent of the MFD, there is actually no need to make the Kconfig depend on MFD_RT5033. Although the driver uses the shared <linux/mfd/rt5033.h> header, there is no compile or runtime dependency on the RT5033 MFD driver. Cc: Beomho Seo <beomho.seo@samsung.com> Cc: Chanwoo Choi <cw00.choi@samsung.com> Fixes: b847dd96e659 ("power: rt5033_battery: Add RT5033 Fuel gauge device driver") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI/sysfs: Fix dsm_label_utf16s_to_utf8s() buffer overrunKrzysztof Wilczyński1-1/+1
[ Upstream commit bdcdaa13ad96f1a530711c29e6d4b8311eff767c ] "utf16s_to_utf8s(..., buf, PAGE_SIZE)" puts up to PAGE_SIZE bytes into "buf" and returns the number of bytes it actually put there. If it wrote PAGE_SIZE bytes, the newline added by dsm_label_utf16s_to_utf8s() would overrun "buf". Reduce the size available for utf16s_to_utf8s() to use so there is always space for the newline. [bhelgaas: reorder patch in series, commit log] Fixes: 6058989bad05 ("PCI: Export ACPI _DSM provided firmware instance number and string name to sysfs") Link: https://lore.kernel.org/r/20210603000112.703037-7-kw@linux.com Reported-by: Joe Perches <joe@perches.com> Signed-off-by: Krzysztof Wilczyński <kw@linux.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20remoteproc: k3-r5: Fix an error messageChristophe JAILLET1-1/+1
[ Upstream commit 34c4da6d5dfba48f49f891ebd75bb55999f0c538 ] 'ret' is known to be 0 here. Reorder the code so that the expected error code is printed. Acked-by: Suman Anna <s-anna@ti.com> Fixes: 6dedbd1d5443 ("remoteproc: k3-r5: Add a remoteproc driver for R5F subsystem") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/d6e29d903b48957bf59c67229d54b0fc215e31ae.1620333870.git.christophe.jaillet@wanadoo.fr Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20virtio_console: Assure used length from device is limitedXie Yongji1-2/+2
[ Upstream commit d00d8da5869a2608e97cfede094dfc5e11462a46 ] The buf->len might come from an untrusted device. This ensures the value would not exceed the size of the buffer to avoid data corruption or loss. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Acked-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210525125622.1203-1-xieyongji@bytedance.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20virtio_net: Fix error handling in virtnet_restore()Xie Yongji1-1/+4
[ Upstream commit 3f2869cace829fb4b80fc53b3ddaa7f4ba9acbf1 ] Do some cleanups in virtnet_restore() when virtnet_cpu_notif_add() failed. Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210517084516.332-1-xieyongji@bytedance.com Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20virtio-blk: Fix memory leak among suspend/resume procedureXie Yongji1-0/+2
[ Upstream commit b71ba22e7c6c6b279c66f53ee7818709774efa1f ] The vblk->vqs should be freed before we call init_vqs() in virtblk_restore(). Signed-off-by: Xie Yongji <xieyongji@bytedance.com> Link: https://lore.kernel.org/r/20210517084332.280-1-xieyongji@bytedance.com Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: rockchip: Register IRQ handlers after device and data are readyJavier Martinez Canillas1-6/+6
[ Upstream commit 3cf5f7ab230e2b886e493c7a8449ed50e29d2b98 ] An IRQ handler may be called at any time after it is registered, so anything it relies on must be ready before registration. rockchip_pcie_subsys_irq_handler() and rockchip_pcie_client_irq_handler() read registers in the PCIe controller, but we registered them before turning on clocks to the controller. If either is called before the clocks are turned on, the register reads fail and the machine hangs. Similarly, rockchip_pcie_legacy_int_handler() uses rockchip->irq_domain, but we installed it before initializing irq_domain. Register IRQ handlers after their data structures are initialized and clocks are enabled. Found by enabling CONFIG_DEBUG_SHIRQ, which calls the IRQ handler when it is being unregistered. An error during the probe path might cause this unregistration and IRQ handler execution before the device or data structure init has finished. [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210608080409.1729276-1-javierm@redhat.com Reported-by: Peter Robinson <pbrobinson@gmail.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Shawn Lin <shawn.lin@rock-chips.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20ACPI: video: Add quirk for the Dell Vostro 3350Hans de Goede1-0/+9
[ Upstream commit 9249c32ec9197e8d34fe5179c9e31668a205db04 ] The Dell Vostro 3350 ACPI video-bus device reports spurious ACPI_VIDEO_NOTIFY_CYCLE events resulting in spurious KEY_SWITCHVIDEOMODE events being reported to userspace (and causing trouble there). Add a quirk setting the report_key_events mask to REPORT_BRIGHTNESS_KEY_EVENTS so that the ACPI_VIDEO_NOTIFY_CYCLE events will be ignored, while still reporting brightness up/down hotkey-presses to userspace normally. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1911763 Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20ACPI: AMBA: Fix resource name in /proc/iomemLiguang Zhang1-0/+1
[ Upstream commit 7718629432676b5ebd9a32940782fe297a0abf8d ] In function amba_handler_attach(), dev->res.name is initialized by amba_device_alloc. But when address_found is false, dev->res.name is assigned to null value, which leads to wrong resource name display in /proc/iomem, "<BAD>" is seen for those resources. Signed-off-by: Liguang Zhang <zhangliguang@linux.alibaba.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20pwm: tegra: Don't modify HW state in .remove callbackUwe Kleine-König1-13/+0
[ Upstream commit 86f7fa71cd830d18d7ebcaf719dffd5ddfe1acdd ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20pwm: img: Fix PM reference leak in img_pwm_enable()Zou Wei1-1/+1
[ Upstream commit fde25294dfd8e36e4e30b693c27a86232864002a ] pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20drm/amdkfd: fix sysfs kobj leakPhilip Yang2-8/+7
[ Upstream commit dcdb4d904b4bd3078fe8d4d24b1658560d6078ef ] 3 cases of kobj leak, which causes memory leak: kobj_type must have release() method to free memory from release callback. Don't need NULL default_attrs to init kobj. sysfs files created under kobj_status should be removed with kobj_status as parent kobject. Remove queue sysfs files when releasing queue from process MMU notifier release callback. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: ab8500: add missing MODULE_DEVICE_TABLEZou Wei3-0/+3
[ Upstream commit dfe52db13ab8d24857a9840ec7ca75eef800c26c ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: charger-manager: add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 073b5d5b1f9cc94a3eea25279fbafee3f4f5f097 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20drm/gma500: Add the missed drm_gem_object_put() in psb_user_framebuffer_create()Jing Xiangfeng1-1/+6
[ Upstream commit cd8f318fbd266b127ffc93cc4c1eaf9a5196fafb ] psb_user_framebuffer_create() misses to call drm_gem_object_put() in an error path. Add the missed function call to fix it. Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210629115956.15160-1-jingxiangfeng@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: tegra: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 7bf475a4614a9722b9b989e53184a02596cf16d1 ] Add missing MODULE_DEVICE_TABLE definition so we generate correct modalias for automatic loading of this driver when it is built as a module. Link: https://lore.kernel.org/r/1620792422-16535-1-git-send-email-zou_wei@huawei.com Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Vidya Sagar <vidyas@nvidia.com> Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20remoteproc: core: Fix cdev remove and rproc delSiddharth Gupta2-2/+2
[ Upstream commit 930eec0be20c93a53160c74005a1485a230e6911 ] The rproc_char_device_remove() call currently unmaps the cdev region instead of simply deleting the cdev that was added as a part of the rproc_char_device_add() call. This change fixes that behaviour, and also fixes the order in which device_del() and cdev_del() need to be called. Signed-off-by: Siddharth Gupta <sidgup@codeaurora.org> Link: https://lore.kernel.org/r/1623723671-5517-4-git-send-email-sidgup@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: iTCO_wdt: Account for rebooting on second timeoutJan Kiszka1-3/+9
[ Upstream commit cb011044e34c293e139570ce5c01aed66a34345c ] This was already attempted to fix via 1fccb73011ea: If the BIOS did not enable TCO SMIs, the timer definitely needs to trigger twice in order to cause a reboot. If TCO SMIs are on, as well as SMIs in general, we can continue to assume that the BIOS will perform a reboot on the first timeout. QEMU with its ICH9 and related BIOS falls into the former category, currently taking twice the configured timeout in order to reboot the machine. For iTCO version that fall under turn_SMI_watchdog_clear_off, this is also true and was currently only addressed for v1, irrespective of the turn_SMI_watchdog_clear_off value. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/0b8bb307-d08b-41b5-696c-305cdac6789c@siemens.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: imx_sc_wdt: fix pretimeoutStefan Eichenberger1-7/+4
[ Upstream commit 854478a381078ee86ae2a7908a934b1ded399130 ] If the WDIOF_PRETIMEOUT flag is not set when registering the device the driver will not show the sysfs entries or register the default governor. By moving the registering after the decision whether pretimeout is supported this gets fixed. Signed-off-by: Stefan Eichenberger <eichest@gmail.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com> Link: https://lore.kernel.org/r/20210519080311.142928-1-eichest@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: Fix possible use-after-free by calling del_timer_sync()Zou Wei2-2/+2
[ Upstream commit d0212f095ab56672f6f36aabc605bda205e1e0bf ] This driver's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Acked-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://lore.kernel.org/r/1620802676-19701-1-git-send-email-zou_wei@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: sc520_wdt: Fix possible use-after-free in wdt_turnoff()Zou Wei1-1/+1
[ Upstream commit 90b7c141132244e8e49a34a4c1e445cce33e07f4 ] This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1620716691-108460-1-git-send-email-zou_wei@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: Fix possible use-after-free in wdt_startup()Zou Wei1-1/+1
[ Upstream commit c08a6b31e4917034f0ed0cb457c3bb209576f542 ] This module's remove path calls del_timer(). However, that function does not wait until the timer handler finishes. This means that the timer handler may still be running after the driver's remove function has finished, which would result in a use-after-free. Fix by calling del_timer_sync(), which makes sure the timer handler has finished, and unable to re-schedule itself. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/1620716495-108352-1-git-send-email-zou_wei@huawei.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Wim Van Sebroeck <wim@linux-watchdog.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: pciehp: Ignore Link Down/Up caused by DPCLukas Wunner3-5/+109
[ Upstream commit a97396c6eb13f65bea894dbe7739b2e883d40a3e ] Downstream Port Containment (PCIe r5.0, sec. 6.2.10) disables the link upon an error and attempts to re-enable it when instructed by the DPC driver. A slot which is both DPC- and hotplug-capable is currently powered off by pciehp once DPC is triggered (due to the link change) and powered back up on successful recovery. That's undesirable, the slot should remain powered so the hotplugged device remains bound to its driver. DPC notifies the driver of the error and of successful recovery in pcie_do_recovery() and the driver may then restore the device to working state. Moreover, Sinan points out that turning off slot power by pciehp may foil recovery by DPC: Power off/on is a cold reset concurrently to DPC's warm reset. Sathyanarayanan reports extended delays or failure in link retraining by DPC if pciehp brings down the slot. Fix by detecting whether a Link Down event is caused by DPC and awaiting recovery if so. On successful recovery, ignore both the Link Down and the subsequent Link Up event. Afterwards, check whether the link is down to detect surprise-removal or another DPC event immediately after DPC recovery. Ensure that the corresponding DLLSC event is not ignored by synthesizing it and invoking irq_wake_thread() to trigger a re-run of pciehp_ist(). The IRQ threads of the hotplug and DPC drivers, pciehp_ist() and dpc_handler(), race against each other. If pciehp is faster than DPC, it will wait until DPC recovery completes. Recovery consists of two steps: The first step (waiting for link disablement) is recognizable by pciehp through a set DPC Trigger Status bit. The second step (waiting for link retraining) is recognizable through a newly introduced PCI_DPC_RECOVERING flag. If DPC is faster than pciehp, neither of the two flags will be set and pciehp may glean the recovery status from the new PCI_DPC_RECOVERED flag. The flag is zero if DPC didn't occur at all, hence DLLSC events are not ignored by default. pciehp waits up to 4 seconds before assuming that DPC recovery failed and bringing down the slot. This timeout is not taken from the spec (it doesn't mandate one) but based on a report from Yicong Yang that DPC may take a bit more than 3 seconds on HiSilicon's Kunpeng platform. The timeout is necessary because the DPC Trigger Status bit may never clear: On Root Ports which support RP Extensions for DPC, the DPC driver polls the DPC RP Busy bit for up to 1 second before giving up on DPC recovery. Without the timeout, pciehp would then wait indefinitely for DPC to complete. This commit draws inspiration from previous attempts to synchronize DPC with pciehp: By Sinan Kaya, August 2018: https://lore.kernel.org/linux-pci/20180818065126.77912-1-okaya@kernel.org/ By Ethan Zhao, October 2020: https://lore.kernel.org/linux-pci/20201007113158.48933-1-haifeng.zhao@intel.com/ By Kuppuswamy Sathyanarayanan, March 2021: https://lore.kernel.org/linux-pci/59cb30f5e5ac6d65427ceaadf1012b2ba8dbf66c.1615606143.git.sathyanarayanan.kuppuswamy@linux.intel.com/ Link: https://lore.kernel.org/r/0be565d97438fe2a6d57354b3aa4e8626952a00b.1619857124.git.lukas@wunner.de Reported-by: Sinan Kaya <okaya@kernel.org> Reported-by: Ethan Zhao <haifeng.zhao@intel.com> Reported-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Tested-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Tested-by: Yicong Yang <yangyicong@hisilicon.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Ashok Raj <ashok.raj@intel.com> Cc: Keith Busch <kbusch@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI/P2PDMA: Avoid pci_get_slot(), which may sleepLogan Gunthorpe1-2/+32
[ Upstream commit 3ec0c3ec2d92c09465534a1ff9c6f9d9506ffef6 ] In order to use upstream_bridge_distance_warn() from a dma_map function, it must not sleep. However, pci_get_slot() takes the pci_bus_sem so it might sleep. In order to avoid this, try to get the host bridge's device from the first element in the device list. It should be impossible for the host bridge's device to go away while references are held on child devices, so the first element should not be able to change and, thus, this should be safe. Introduce a static function called pci_host_bridge_dev() to obtain the host bridge's root device. Link: https://lore.kernel.org/r/20210610160609.28447-7-logang@deltatee.com Signed-off-by: Logan Gunthorpe <logang@deltatee.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: reset: gpio-poweroff: add missing MODULE_DEVICE_TABLEBixuan Cui1-0/+1
[ Upstream commit ed3443fb4df4e140a22f65144546c8a8e1e27f4e ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Bixuan Cui <cuibixuan@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: max17042: Do not enforce (incorrect) interrupt trigger typeKrzysztof Kozlowski1-1/+1
[ Upstream commit 7fbf6b731bca347700e460d94b130f9d734b33e9 ] Interrupt line can be configured on different hardware in different way, even inverted. Therefore driver should not enforce specific trigger type - edge falling - but instead rely on Devicetree to configure it. The Maxim 17047/77693 datasheets describe the interrupt line as active low with a requirement of acknowledge from the CPU therefore the edge falling is not correct. The interrupt line is shared between PMIC and RTC driver, so using level sensitive interrupt is here especially important to avoid races. With an edge configuration in case if first PMIC signals interrupt followed shortly after by the RTC, the interrupt might not be yet cleared/acked thus the second one would not be noticed. Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: hv: Fix a race condition when removing the deviceLong Li1-7/+23
[ Upstream commit 94d22763207ac6633612b8d8e0ca4fba0f7aa139 ] On removing the device, any work item (hv_pci_devices_present() or hv_pci_eject_device()) scheduled on workqueue hbus->wq may still be running and race with hv_pci_remove(). This can happen because the host may send PCI_EJECT or PCI_BUS_RELATIONS(2) and decide to rescind the channel immediately after that. Fix this by flushing/destroying the workqueue of hbus before doing hbus remove. Link: https://lore.kernel.org/r/1620806800-30983-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Long Li <longli@microsoft.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: ab8500: Avoid NULL pointersLinus Walleij1-1/+17
[ Upstream commit 5bcb5087c9dd3dca1ff0ebd8002c5313c9332b56 ] Sometimes the code will crash because we haven't enabled AC or USB charging and thus not created the corresponding psy device. Fix it by checking that it is there before notifying. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: ftpci100: Rename macro name collisionRandy Dunlap1-15/+15
[ Upstream commit 5be967d5016ac5ffb9c4d0df51b48441ee4d5ed1 ] PCI_IOSIZE is defined in mach-loongson64/spaces.h, so change the name of the PCI_* macros in pci-ftpci100.c to use FTPCI_* so that they are more localized and won't conflict with other drivers or arches. ../drivers/pci/controller/pci-ftpci100.c:37: warning: "PCI_IOSIZE" redefined 37 | #define PCI_IOSIZE 0x00 | In file included from ../arch/mips/include/asm/addrspace.h:13, ... from ../drivers/pci/controller/pci-ftpci100.c:15: arch/mips/include/asm/mach-loongson64/spaces.h:11: note: this is the location of the previous definition 11 | #define PCI_IOSIZE SZ_16M Suggested-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210517234117.3660-1-rdunlap@infradead.org Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Krzysztof Wilczyński <kw@linux.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: linux-mips@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20pwm: spear: Don't modify HW state in .remove callbackUwe Kleine-König1-4/+0
[ Upstream commit b601a18f12383001e7a8da238de7ca1559ebc450 ] A consumer is expected to disable a PWM before calling pwm_put(). And if they didn't there is hopefully a good reason (or the consumer needs fixing). Also if disabling an enabled PWM was the right thing to do, this should better be done in the framework instead of in each low level driver. So drop the hardware modification from the .remove() callback. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: sc2731_charger: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 2aac79d14d76879c8e307820b31876e315b1b242 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: sc27xx: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 603fcfb9d4ec1cad8d66d3bb37f3613afa8a661a ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20phy: intel: Fix for warnings due to EMMC clock 175Mhz change in FIPRashmi A1-1/+2
[ Upstream commit 2f2b73a29d2aabf5ad0150856c3e5cb6e04dcfc1 ] Since the EMMC clock was changed from 200Mhz to 175Mhz in FIP, there were some warnings introduced, as the frequency values being checked was still wrt 200Mhz in code. Hence, the frequency checks are now updated based on the current 175Mhz EMMC clock changed in FIP. Spamming kernel log msg: "phy phy-20290000.mmc_phy.2: Unsupported rate: 43750000" Signed-off-by: Rashmi A <rashmi.a@intel.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com> Acked-By: Vinod Koul <vkoul@kernel.org> Link: https://lore.kernel.org/r/20210603182242.25733-3-rashmi.a@intel.com Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20i2c: core: Disable client irq on reboot/shutdownDmitry Torokhov1-0/+3
[ Upstream commit b64210f2f7c11c757432ba3701d88241b2b98fb1 ] If an i2c client receives an interrupt during reboot or shutdown it may be too late to service it by making an i2c transaction on the bus because the i2c controller has already been shutdown. This can lead to system hangs if the i2c controller tries to make a transfer that is doomed to fail because the access to the i2c pins is already shut down, or an iommu translation has been torn down so i2c controller register access doesn't work. Let's simply disable the irq if there isn't a shutdown callback for an i2c client when there is an irq associated with the device. This will make sure that irqs don't come in later than the time that we can handle it. We don't do this if the i2c client device already has a shutdown callback because presumably they're doing the right thing and quieting the device so irqs don't come in after the shutdown callback returns. Reported-by: kernel test robot <lkp@intel.com> [swboyd@chromium.org: Dropped newline, added commit text, added interrupt.h for robot build error] Signed-off-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Wolfram Sang <wsa@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20intel_th: Wait until port is in reset before programming itAlexander Shishkin3-0/+36
[ Upstream commit ab1afed701d2db7eb35c1a2526a29067a38e93d1 ] Some devices don't drain their pipelines if we don't make sure that the corresponding output port is in reset before programming it for a new trace capture, resulting in bits of old trace appearing in the new trace capture. Fix that by explicitly making sure the reset is asserted before programming new trace capture. Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Alexander Shishkin <alexander.shishkin@linux.intel.com> Link: https://lore.kernel.org/r/20210621151246.31891-5-alexander.shishkin@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20staging: rtl8723bs: fix macro value for 2.4Ghz only deviceFabio Aiuto1-4/+1
[ Upstream commit 6d490a27e23c5fb79b766530016ab8665169498e ] fix IQK_Matrix_Settings_NUM macro value to 14 which is the max channel number value allowed in a 2.4Ghz device. Acked-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com> Link: https://lore.kernel.org/r/0b4a876929949248aa18cb919da3583c65e4ee4e.1624367072.git.fabioaiuto83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20leds: turris-omnia: add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 9d0150db97583cfbb6b44cbe02241a1a48f90210 ] This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Zou Wei <zou_wei@huawei.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20backlight: lm3630a: Fix return code of .update_status() callbackUwe Kleine-König1-6/+6
[ Upstream commit b9481a667a90ec739995e85f91f3672ca44d6ffa ] According to <linux/backlight.h> .update_status() is supposed to return 0 on success and a negative error code otherwise. Adapt lm3630a_bank_a_update_status() and lm3630a_bank_b_update_status() to actually do it. While touching that also add the error code to the failure message. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20usb: gadget: hid: fix error return code in hid_bind()Yang Yingliang1-1/+3
[ Upstream commit 88693f770bb09c196b1eb5f06a484a254ecb9924 ] Fix to return a negative error code from the error handling case instead of 0. Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Link: https://lore.kernel.org/r/20210618043835.2641360-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20usb: gadget: f_hid: fix endianness issue with descriptorsRuslan Bilovol1-1/+1
[ Upstream commit 33cb46c4676d01956811b68a29157ea969a5df70 ] Running sparse checker it shows warning message about incorrect endianness used for descriptor initialization: | f_hid.c:91:43: warning: incorrect type in initializer (different base types) | f_hid.c:91:43: expected restricted __le16 [usertype] bcdHID | f_hid.c:91:43: got int Fixing issue with cpu_to_le16() macro, however this is not a real issue as the value is the same both endians. Cc: Fabien Chouteau <fabien.chouteau@barco.com> Cc: Segiy Stetsyuk <serg_stetsuk@ukr.net> Signed-off-by: Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/20210617162755.29676-1-ruslan.bilovol@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20Input: hideep - fix the uninitialized use in hideep_nvm_unlock()Yizhuo Zhai1-3/+10
[ Upstream commit cac7100d4c51c04979dacdfe6c9a5e400d3f0a27 ] Inside function hideep_nvm_unlock(), variable "unmask_code" could be uninitialized if hideep_pgm_r_reg() returns error, however, it is used in the later if statement after an "and" operation, which is potentially unsafe. Signed-off-by: Yizhuo <yzhai003@ucr.edu> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20habanalabs: remove node from list before freeing the nodeKoby Elbaz2-0/+2
[ Upstream commit f5eb7bf0c487a212ebda3c1b048fc3ccabacc147 ] fix the following smatch warnings: goya_pin_memory_before_cs() warn: '&userptr->job_node' not removed from list gaudi_pin_memory_before_cs() warn: '&userptr->job_node' not removed from list Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20habanalabs/gaudi: set the correct cpu_id on MME2_QM failureKoby Elbaz1-1/+1
[ Upstream commit b92c637c5f5ef7e3e21dbc7bfa7f1999450f3902 ] This fix was applied since there was an incorrect reported CPU ID to GIC such that an error in MME2 QMAN aliased to be an arriving from DMA0_QM. Signed-off-by: Koby Elbaz <kelbaz@habana.ai> Reviewed-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Oded Gabbay <ogabbay@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20gpio: pca953x: Add support for the On Semi pca9655Peter Robinson1-0/+1
[ Upstream commit 6d49b3a0f351925b5ea5047166c112b7590b918a ] The On Semi pca9655 is a 16 bit variant of the On Semi pca9654 GPIO expander, with 16 GPIOs and interrupt functionality. Signed-off-by: Peter Robinson <pbrobinson@gmail.com> [Bartosz: fixed indentation as noted by Andy] Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20scsi: storvsc: Correctly handle multiple flags in srb_statusMichael Kelley1-28/+33
[ Upstream commit 52e1b3b3daa9d53f0204bf474ee1d4b1beb38234 ] Hyper-V is observed to sometimes set multiple flags in the srb_status, such as ABORTED and ERROR. Current code in storvsc_handle_error() handles only a single flag being set, and does nothing when multiple flags are set. Fix this by changing the case statement into a series of "if" statements testing individual flags. The functionality for handling each flag is unchanged. Link: https://lore.kernel.org/r/1622827263-12516-3-git-send-email-mikelley@microsoft.com Signed-off-by: Michael Kelley <mikelley@microsoft.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20gpio: zynq: Check return value of irq_get_irq_dataSrinivas Neeli1-0/+10
[ Upstream commit 35d7b72a632bc7afb15356f44005554af8697904 ] In two different instances the return value of "irq_get_irq_data" API was neither captured nor checked. Fixed it by capturing the return value and then checking for any error. Addresses-Coverity: "returned_null" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20gpio: zynq: Check return value of pm_runtime_get_syncSrinivas Neeli1-1/+4
[ Upstream commit a51b2fb94b04ab71e53a71b9fad03fa826941254 ] Return value of "pm_runtime_get_sync" API was neither captured nor checked. Fixed it by capturing the return value and then checking for any warning. Addresses-Coverity: "check_return" Signed-off-by: Srinivas Neeli <srinivas.neeli@xilinx.com> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20iommu/arm-smmu: Fix arm_smmu_device refcount leak in address translationXiyu Yang1-2/+6
[ Upstream commit 7c8f176d6a3fa18aa0f8875da6f7c672ed2a8554 ] The reference counting issue happens in several exception handling paths of arm_smmu_iova_to_phys_hard(). When those error scenarios occur, the function forgets to decrease the refcount of "smmu" increased by arm_smmu_rpm_get(), causing a refcount leak. Fix this issue by jumping to "out" label when those error scenarios occur. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Reviewed-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/1623293391-17261-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-24 14:42:36 +0000