summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-07-20nvme-tcp: can't set sk_user_data without write_lockMaurizio Lombardi1-1/+0
[ Upstream commit 0755d3be2d9bb6ea38598ccd30d6bbaa1a5c3a50 ] The sk_user_data pointer is supposed to be modified only while holding the write_lock "sk_callback_lock", otherwise we could race with other threads and crash the kernel. we can't take the write_lock in nvmet_tcp_state_change() because it would cause a deadlock, but the release_work queue will set the pointer to NULL later so we can simply remove the assignment. Fixes: b5332a9f3f3d ("nvmet-tcp: fix incorrect locking in state_change sk callback") Signed-off-by: Maurizio Lombardi <mlombard@redhat.com> Reviewed-by: Sagi Grimberg <sagi@grimberg.me> Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20virtio_net: move tx vq operation under tx queue lockMichael S. Tsirkin1-1/+21
[ Upstream commit 5a2f966d0f3fa0ef6dada7ab9eda74cacee96b8a ] It's unsafe to operate a vq from multiple threads. Unfortunately this is exactly what we do when invoking clean tx poll from rx napi. Same happens with napi-tx even without the opportunistic cleaning from the receive interrupt: that races with processing the vq in start_xmit. As a fix move everything that deals with the vq to under tx lock. Fixes: b92f1e6751a6 ("virtio-net: transmit napi") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20vdp/mlx5: Fix setting the correct dma_deviceEli Cohen2-8/+3
[ Upstream commit 7d23dcdf213c2e5f097eb7eec3148c26eb01d59f ] Before SF support was introduced, the DMA device was equal to mdev->device which was in essence equal to pdev->dev. With SF introduction this is no longer true. It has already been handled for vhost_vdpa since the reference to the dma device can from within mlx5_vdpa. With virtio_vdpa this broke. To fix this we set the real dma device when initializing the device. In addition, for the sake of consistency, previous references in the code to the dma device are changed to vdev->dma_dev. Fixes: d13a15d544ce5 ("vdpa/mlx5: Use the correct dma device when registering memory") Signed-off-by: Eli Cohen <elic@nvidia.com> Link: https://lore.kernel.org/r/20210606053150.170489-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20vdpa/mlx5: Fix possible failure in umem size calculationEli Cohen1-10/+5
[ Upstream commit 71ab6a7cfbae27f86a3901daab10bfe13b3a1e3a ] umem size is a 32 bit unsigned value so assigning it to an int could cause false failures. Set the calculated value inside the function and modify function name to reflect the fact it updates the size. This bug was found during code review but never had real impact to this date. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen <elic@nvidia.com> Link: https://lore.kernel.org/r/20210530090349.8360-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20vdpa/mlx5: Fix umem sizes assignments on VQ createEli Cohen1-2/+2
[ Upstream commit e3011776af16caf423f2c36d0047acd624c274fa ] Fix copy paste bug assigning umem1 size to umem2 and umem3. The issue was discovered when trying to use a 1:1 MR that covers the entire address space where firmware complained that provided sizes are not large enough. 1:1 MRs are required to support virtio_vdpa. Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices") Signed-off-by: Eli Cohen <elic@nvidia.com> Link: https://lore.kernel.org/r/20210530090317.8284-1-elic@nvidia.com Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Jason Wang <jasowang@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20vp_vdpa: correct the return value when fail to map notificationJason Wang1-0/+1
[ Upstream commit 94e48d6aafef23143f92eadd010c505c49487576 ] We forget to assign a error value when we fail to map the notification during prove. This patch fixes it. Reported-by: kernel test robot <lkp@intel.com> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: 11d8ffed00b23 ("vp_vdpa: switch to use vp_modern_map_vq_notify()") Signed-off-by: Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20210624035939.26618-1-jasowang@redhat.com Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20arch_topology: Avoid use-after-free for scale_freq_dataViresh Kumar1-6/+21
[ Upstream commit 83150f5d05f065fb5c12c612f119015cabdcc124 ] Currently topology_scale_freq_tick() (which gets called from scheduler_tick()) may end up using a pointer to "struct scale_freq_data", which was previously cleared by topology_clear_scale_freq_source(), as there is no protection in place here. The users of topology_clear_scale_freq_source() though needs a guarantee that the previously cleared scale_freq_data isn't used anymore, so they can free the related resources. Since topology_scale_freq_tick() is called from scheduler tick, we don't want to add locking in there. Use the RCU update mechanism instead (which is already used by the scheduler's utilization update path) to guarantee race free updates here. synchronize_rcu() makes sure that all RCU critical sections that started before it is called, will finish before it returns. And so the callers of topology_clear_scale_freq_source() don't need to worry about their callback getting called anymore. Cc: Paul E. McKenney <paulmck@kernel.org> Fixes: 01e055c120a4 ("arch_topology: Allow multiple entities to provide sched_freq_tick() callback") Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Tested-by: Qian Cai <quic_qiancai@quicinc.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: tegra194: Fix tegra_pcie_ep_raise_msi_irq() ill-defined shiftJon Hunter1-1/+1
[ Upstream commit f67092eff2bd40650aad54a1a1910160f41d864a ] tegra_pcie_ep_raise_msi_irq() shifted a signed 32-bit value left by 31 bits. The behavior of this is implementation-defined. Replace the shift by BIT(), which is well-defined. Found by cppcheck: $ cppcheck --enable=all drivers/pci/controller/dwc/pcie-tegra194.c Checking drivers/pci/controller/dwc/pcie-tegra194.c ... drivers/pci/controller/dwc/pcie-tegra194.c:1829:23: portability: Shifting signed 32-bit value by 31 bits is implementation-defined behaviour. See condition at line 1826. [shiftTooManyBitsSigned] appl_writel(pcie, (1 << irq), APPL_MSI_CTRL_1); ^ [bhelgaas: commit log] Link: https://lore.kernel.org/r/20210618160219.303092-1-jonathanh@nvidia.com Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20pwm: imx1: Don't disable clocks at device remove timeUwe Kleine-König1-2/+0
[ Upstream commit 1bc6ea31cb41d50302a3c9b401964cf0a88d41f9 ] The .remove() callback disables clocks that were not enabled in .probe(). So just probing and then unbinding the driver results in a clk enable imbalance. So just drop the call to disable the clocks. (Which BTW was also in the wrong order because the call makes the PWM unfunctional and so should have come only after pwmchip_remove()). Fixes: 9f4c8f9607c3 ("pwm: imx: Add ipg clock operation") 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-20PCI: intel-gw: Fix INTx enableMartin Blumenstingl1-4/+6
[ Upstream commit 655832d12f2251e04031294f547c86935a0a126d ] The legacy PCI interrupt lines need to be enabled using PCIE_APP_IRNEN bits 13 (INTA), 14 (INTB), 15 (INTC) and 16 (INTD). The old code however was taking (for example) "13" as raw value instead of taking BIT(13). Define the legacy PCI interrupt bits using the BIT() macro and then use these in PCIE_APP_IRN_INT. Link: https://lore.kernel.org/r/20210106135540.48420-1-martin.blumenstingl@googlemail.com Fixes: ed22aaaede44 ("PCI: dwc: intel: PCIe RC controller driver") Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Rahul Tanwar <rtanwar@maxlinear.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: iproc: Support multi-MSI only on uniprocessor kernelSandor Bodo-Merle1-1/+7
[ Upstream commit 2dc0a201d0f59e6818ef443609f0850a32910844 ] The interrupt affinity scheme used by this driver is incompatible with multi-MSI as it implies moving the doorbell address to that of another MSI group. This isn't possible for multi-MSI, as all the MSIs must have the same doorbell address. As such it is restricted to systems with a single CPU. Link: https://lore.kernel.org/r/20210622152630.40842-2-sbodomerle@gmail.com Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Sandor Bodo-Merle <sbodomerle@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Pali Rohár <pali@kernel.org> Acked-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20PCI: iproc: Fix multi-MSI base vector number allocationSandor Bodo-Merle1-10/+11
[ Upstream commit e673d697b9a234fc3544ac240e173cef8c82b349 ] Commit fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") introduced multi-MSI support with a broken allocation mechanism (it failed to reserve the proper number of bits from the inner domain). Natural alignment of the base vector number was also not guaranteed. Link: https://lore.kernel.org/r/20210622152630.40842-1-sbodomerle@gmail.com Fixes: fc54bae28818 ("PCI: iproc: Allow allocation of multiple MSIs") Reported-by: Pali Rohár <pali@kernel.org> Signed-off-by: Sandor Bodo-Merle <sbodomerle@gmail.com> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Acked-by: Pali Rohár <pali@kernel.org> Acked-by: Ray Jui <ray.jui@broadcom.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20watchdog: jz4740: Fix return value check in jz4740_wdt_probe()Wei Yongjun1-2/+2
[ Upstream commit 29e85f53fb58b45b9e9276dcdf1f1cb762dd1c9f ] In case of error, the function device_node_to_regmap() returns ERR_PTR() and never returns NULL. The NULL test in the return value check should be replaced with IS_ERR(). Fixes: 6d532143c915 ("watchdog: jz4740: Use regmap provided by TCU driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com> Acked-by: Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20210304045909.945799-1-weiyongjun1@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: 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-20watchdog: keembay: Removed timeout update in the TO ISRShruthi Sanil1-1/+0
[ Upstream commit 3168be5d66ac6c3508a880022f79b5a887865d5d ] In the TO ISR removed updating the Timeout value because its not serving any purpose as the timer would have already expired and the system would be rebooting. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-7-shruthi.sanil@intel.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: keembay: Remove timeout update in the WDT start functionShruthi Sanil1-1/+0
[ Upstream commit 9eb25269271c679e8cfcc7df5c0c5e9d0572fc27 ] Removed set timeout from the start WDT function. There is a function defined to set the timeout. Hence no need to set the timeout again in start function as the timeout would have been already updated before calling the start/enable. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-6-shruthi.sanil@intel.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: keembay: Clear either the TO or TH interrupt bitShruthi Sanil1-3/+4
[ Upstream commit 0e36a09faea25f4564d41a0c28938199b605148e ] During the interrupt service routine of the TimeOut interrupt and the ThresHold interrupt, the respective interrupt clear bit have to be cleared and not both. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-5-shruthi.sanil@intel.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: keembay: Update pretimeout to zero in the TH ISRShruthi Sanil1-0/+2
[ Upstream commit 75f6c56dfeec92c53e09a72896547888ac9a27d7 ] The pretimeout has to be updated to zero during the ISR of the ThresHold interrupt. Else the TH interrupt would be triggerred for every tick until the timeout. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-4-shruthi.sanil@intel.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: keembay: Upadate WDT pretimeout for every update in timeoutShruthi Sanil1-0/+1
[ Upstream commit 0f7bfaf10c0abc979220442bae2af4f1f869c41e ] The pre-timeout value to be programmed to the register has to be calculated and updated for every change in the timeout value. Else the threshold time wouldn't be calculated to its corresponding timeout. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-3-shruthi.sanil@intel.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: keembay: Update WDT pre-timeout during the initializationShruthi Sanil1-0/+3
[ Upstream commit 29353816300c79cb5157ed2719cc71285c7b77aa ] The pretimeout register has a default reset value. Hence when a smaller WDT timeout is set which would be lesser than the default pretimeout, the system behaves abnormally, starts triggering the pretimeout interrupt even when the WDT is not enabled, most of the times leading to system crash. Hence an update in the pre-timeout is also required for the default timeout that is being configured. Fixes: fa0f8d51e90d ("watchdog: Add watchdog driver for Intel Keembay Soc") Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Tested-by: Kris Pan <kris.pan@intel.com> Signed-off-by: Shruthi Sanil <shruthi.sanil@intel.com> Link: https://lore.kernel.org/r/20210517174953.19404-2-shruthi.sanil@intel.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-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-20power: supply: surface-charger: Fix type of integer variableMaximilian Luz1-1/+1
[ Upstream commit 601423bc0c06467d019cf2a446962a5bf1b5e330 ] The ac->state field is __le32, not u32. So change the variable we're temporarily storing it in to __le32 as well. Reported-by: kernel test robot <lkp@intel.com> Fixes: e61ffb344591 ("power: supply: Add AC driver for Surface Aggregator Module") Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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-20remoteproc: stm32: fix phys_addr_t format stringArnd Bergmann1-1/+1
[ Upstream commit 3e25e407a1c93b53a87a7743ea0cd4703d3985b7 ] A phys_addr_t may be wider than an int or pointer: drivers/remoteproc/stm32_rproc.c: In function 'stm32_rproc_da_to_pa': drivers/remoteproc/stm32_rproc.c:583:30: error: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'phys_addr_t' {aka 'long long unsigned int'} [-Werror=format=] 583 | dev_dbg(dev, "da %llx to pa %#x\n", da, *pa); Print it by reference using the special %pap format string. Reviewed-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Fixes: 8a471396d21c ("remoteproc: stm32: Move resource table setup to rproc_ops") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20210421140053.3727528-1-arnd@kernel.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20pwm: visconti: Fix and simplify period calculationUwe Kleine-König1-10/+7
[ Upstream commit 937efa29e70f7f8424b74631375dcb35d82a4614 ] With the original code a request for period = 65536000 ns and period = 32768000 ns yields the same register settings (which results in 32768000 ns) because the value for pwmc0 was miscalculated. Also simplify using that fls(0) is 0. Fixes: 721b595744f1 ("pwm: visconti: Add Toshiba Visconti SoC PWM support") Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> Signed-off-by: Thierry Reding <thierry.reding@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20cpufreq: scmi: Fix an error messageChristophe JAILLET1-1/+1
[ Upstream commit b791c7f94680ba9b60b0c0786b1d0eb4393053d6 ] 'ret' is known to be 0 here. The last error code is stored in 'nr_opp', so use it in the error message. Fixes: 71a37cd6a59d ("scmi-cpufreq: Remove deferred probe") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: surface_battery: Fix battery event handlingMaximilian Luz1-2/+12
[ Upstream commit e633f33d2669cb54db2846f9cde08662d254dbd3 ] The battery subsystem of the Surface Aggregator Module EC requires us to register the battery notifier with instance ID 0. However, battery events are actually sent with the instance ID corresponding to the device, which is nonzero. Thus, the strict-matching approach doesn't work here and will discard events that the driver is expected to handle. To fix this we have to fall back on notifier matching by target-category only and have to manually check the instance ID in the notifier callback. Fixes: 167f77f7d0b3 ("power: supply: Add battery driver for Surface Aggregator Module") Signed-off-by: Maximilian Luz <luzmaximilian@gmail.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com> 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-20drm/amdgpu: fix Navi1x tcp power gating hang when issuing lightweight ↵Evan Quan1-0/+95
invalidaiton [ Upstream commit 9c26ddb1c5b6e30c6bca48b8ad9205d96efe93d0 ] Fix TCP hang when a lightweight invalidation happens on Navi1x. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-07-20power: supply: axp288_fuel_gauge: Make "T3 MRD" no_battery_list DMI entry ↵Hans de Goede1-9/+9
more generic [ Upstream commit 3a06b912a5ce494d7b7300b12719c562be7b566f ] It turns out that the "T3 MRD" DMI_BOARD_NAME value is used in a lot of different Cherry Trail x5-z8300 / x5-z8350 based Mini-PC / HDMI-stick models from Ace PC / Meegopad / MinisForum / Wintel (and likely also other vendors). Most of the other DMI strings on these boxes unfortunately contain various generic values like "Default string" or "$(DEFAULT_STRING)", so we cannot match on them. These devices do have their chassis-type correctly set to a value of "3" (desktop) which is a pleasant surprise, so also match on that. This should avoid the quirk accidentally also getting applied to laptops / tablets (which do actually have a battery). Although in my quite large database of Bay and Cherry Trail based devices DMIdecode dumps I don't have any laptops / tables with a board-name of "T3 MRD", so this should not be an issue. BugLink: https://askubuntu.com/questions/1206714/how-can-a-mini-pc-be-stopped-from-being-detected-as-a-laptop-with-a-battery/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.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-20power: reset: regulator-poweroff: add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 4465b3a621e761d82d1a92e3fda88c5d33c804b8 ] 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: stm32: fix mbox_send_message callArnaud Pouliquen1-9/+5
[ Upstream commit 51c4b4e212269a8634dee2000182cfca7f11575b ] mbox_send_message is called by passing a local dummy message or a function parameter. As the message is queued, it is dereferenced. This works because the message field is not used by the stm32 ipcc driver, but it is not clean. Fix by passing a constant string in all cases. The associated comments are removed because rproc should not have to deal with the behavior of the mailbox frame. Reported-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com> Link: https://lore.kernel.org/r/20210420091922.29429-1-arnaud.pouliquen@foss.st.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> 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-20PCI: mediatek-gen3: Add missing MODULE_DEVICE_TABLEZou Wei1-0/+1
[ Upstream commit 3a2e476dc5d02af3422143b07d8db1eced475314 ] 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. Link: https://lore.kernel.org/r/1620717091-108691-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> Reviewed-by: Krzysztof Wilczyński <kw@linux.com> 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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-29 08:21:16 +0300