- 27 Jan, 2020 40 commits
-
-
Yoshihiro Kaneko authored
[ Upstream commit 56d651e8 ] Since the R8A77995 SoC uses DU{0,1}, the range from the base address to the 0x4000 address is used. This patch fixed it. Fixes: 18f1a773 ("arm64: dts: renesas: r8a77995: add DU support") Signed-off-by:
Yoshihiro Kaneko <ykaneko0929@gmail.com> Reviewed-by:
Simon Horman <horms+renesas@verge.net.au> Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Johannes Berg authored
[ Upstream commit f474808a ] A lot of places in the driver use onyx_read_register() without checking the return value, and it's been working OK for ~10 years or so, so probably never fails ... Rather than trying to check the return value everywhere, which would be relatively intrusive, at least make sure we don't use an uninitialized value. Fixes: f3d9478b ("[ALSA] snd-aoa: add snd-aoa") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 72c8117a ] Each of the operations in ccp_run_cmd() needs several hundred bytes of kernel stack. Depending on the inlining, these may need separate stack slots that add up to more than the warning limit, as shown in this clang based build: drivers/crypto/ccp/ccp-ops.c:871:12: error: stack frame size of 1164 bytes in function 'ccp_run_aes_cmd' [-Werror,-Wframe-larger-than=] static int ccp_run_aes_cmd(struct ccp_cmd_queue *cmd_q, struct ccp_cmd *cmd) The problem may also happen when there is no warning, e.g. in the ccp_run_cmd()->ccp_run_aes_cmd()->ccp_run_aes_gcm_cmd() call chain with over 2000 bytes. Mark each individual function as 'noinline_for_stack' to prevent this from happening, and move the calls to the two special cases for aes into the top-level function. This will keep the actual combined stack usage to the mimimum: 828 bytes for ccp_run_aes_gcm_cmd() and at most 524 bytes for each of the other cases. Fixes: 63b94509 ("crypto: ccp - CCP device driver and interface support") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Thomas Gleixner authored
[ Upstream commit 2591bc4e ] apic->send_IPI_allbutself() takes a vector number as argument. APIC_DM_NMI is clearly not a vector number. It's defined to 0x400 which is outside the vector space. Use NMI_VECTOR instead as that's what it is intended to be. Fixes: 82da3ff8 ("x86: kgdb support") Signed-off-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20190722105218.855189979@linutronix.deSigned-off-by:
-
Arnd Bergmann authored
[ Upstream commit bc83f79b ] Generally, declaring a platform device as a static variable is a bad idea and can cause all kinds of problems, in particular with the DMA configuration and lifetime rules. A specific problem we hit here is from a bug in clang that warns about certain (otherwise valid) macros when used in static variables: drivers/misc/mic/card/mic_x100.c:285:27: warning: shift count >= width of type [-Wshift-count-overflow] static u64 mic_dma_mask = DMA_BIT_MASK(64); ^~~~~~~~~~~~~~~~ include/linux/dma-mapping.h:141:54: note: expanded from macro 'DMA_BIT_MASK' #define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1)) ^ ~~~ A slightly better way here is to create the platform device dynamically and set the dma mask in the probe function. This avoids the warning and some other problems, but is still not ideal because the device creation should really be separated from the driver, and the fact that the device has no parent means we have to force the dma mask rather than having it set up from the bus that the device is actually on. Fixes: dd8d8d44 ("misc: mic: MIC card driver specific changes to enable SCIF") Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Niklas Söderlund authored
[ Upstream commit 0bd46576 ] The parallel input initialization error path cleans up the wrong async notifier, fix this by cleaning up the correct notifier. Fixes: 9863bc86 ("media: rcar-vin: Cleanup notifier in error path") Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by:
Jacopo Mondi <jacopo+renesas@jmondi.org> Tested-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
-
Ruslan Bilovol authored
[ Upstream commit 6269e4c7 ] Don't do extra cpu_to_le32 conversion for put_unaligned_le32 because it is already implemented in this function. Fixes sparse error: xhci-hub.c:1152:44: warning: incorrect type in argument 1 (different base types) xhci-hub.c:1152:44: expected unsigned int [usertype] val xhci-hub.c:1152:44: got restricted __le32 [usertype] Fixes: 395f5409 "xhci: support new USB 3.1 hub request to get extended port status" Cc: Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
Ruslan Bilovol <ruslan.bilovol@gmail.com> Link: https://lore.kernel.org/r/1562501839-26522-1-git-send-email-ruslan.bilovol@gmail.comSigned-off-by:
-
Arnd Bergmann authored
[ Upstream commit 7c116e02 ] clang warns about an overly large stack frame in one function when it decides to inline all __qed_get_vport_*() functions into __qed_get_vport_stats(): drivers/net/ethernet/qlogic/qed/qed_l2.c:1889:13: error: stack frame size of 1128 bytes in function '_qed_get_vport_stats' [-Werror,-Wframe-larger-than=] Use a noinline_for_stack annotation to prevent clang from inlining these, which keeps the maximum stack usage at around half of that in the worst case, similar to what we get with gcc. Fixes: 86622ee7 ("qed: Move statistics to L2 code") Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 2ec4ad49 ] It seems we should use 'range' instead of 'priv->range' in lbtf_geo_init(), because 'range' is the corret one related to current regioncode. Reported-by:
Hulk Robot <hulkci@huawei.com> Fixes: 691cdb49 ("libertas_tf: command helper functions for libertas_tf") Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 2933954b ] It is not actually guaranteed that pm_abort_suspend will be nonzero when pm_system_cancel_wakeup() is called which may lead to subtle issues, so make it use atomic_dec_if_positive() instead of atomic_dec() for the safety sake. Fixes: 33e4f80e ("ACPI / PM: Ignore spurious SCI wakeups from suspend-to-idle") Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by:
-
Icenowy Zheng authored
[ Upstream commit c5ed9475 ] The user manual of V3/V3s/S3 declares a PLL_DDR1, however it's forgot when developing the V3s CCU driver. Add back the missing PLL_DDR1. Fixes: d0f11d14 ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Signed-off-by:
-
Jani Nikula authored
[ Upstream commit bf3f5e98 ] Fix build warning if drm_panel.h is built with CONFIG_OF=n or CONFIG_DRM_PANEL=n and included without the prerequisite err.h: ./include/drm/drm_panel.h: In function ‘of_drm_find_panel’: ./include/drm/drm_panel.h:203:9: error: implicit declaration of function ‘ERR_PTR’ [-Werror=implicit-function-declaration] return ERR_PTR(-ENODEV); ^~~~~~~ ./include/drm/drm_panel.h:203:9: error: returning ‘int’ from a function with return type ‘struct drm_panel *’ makes pointer from integer without a cast [-Werror=int-conversion] return ERR_PTR(-ENODEV); ^~~~~~~~~~~~~~~~ Fixes: 5fa8e4a2 ("drm/panel: Make of_drm_find_panel() return an ERR_PTR() instead of NULL") Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Acked-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Sean Paul <sean@poorly.run> Cc: Boris Brezillon <bbrezillon@kernel.org> Signed-off-by:
-
Nicolas Dichtel authored
[ Upstream commit e0aaa332 ] The ifname is copied when the interface is created, but is never updated later. In fact, this property is used only in one error message, where the netdevice pointer is available, thus let's use it. Fixes: f203b76d ("xfrm: Add virtual xfrm interfaces") Signed-off-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 41a6bf65 ] Currently if lport is null then the null lport pointer is dereference when printing out debug via the FC_LPORT_DB macro. Fix this by using the more generic FC_LIBFC_DBG debug macro instead that does not use lport. Addresses-Coverity: ("Dereference after null check") Fixes: 7414705e ("libfc: Add runtime debugging with debug_logging module parameter") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 7e8a0f10 ] This appeared after the global fixups by commit e3246542 ("ARM: use "depends on" for SoC configs instead of "if" after prompt"). Fix it now. Link: https://lore.kernel.org/r/20190710051320.8738-1-yamada.masahiro@socionext.com Fixes: e3246542 ("ARM: use "depends on" for SoC configs instead of "if" after prompt") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Ilya Maximets authored
[ Upstream commit 67571640 ] Completion queue address reservation could not be undone. In case of bad 'queue_id' or skb allocation failure, reserved entry will be leaked reducing the total capacity of completion queue. Fix that by moving reservation to the point where failure is not possible. Additionally, 'queue_id' checking moved out from the loop since there is no point to check it there. Fixes: 35fcde7f ("xsk: support for Tx") Signed-off-by:
Ilya Maximets <i.maximets@samsung.com> Acked-by:
Björn Töpel <bjorn.topel@intel.com> Tested-by:
William Tu <u9012063@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit 26515699 ] clang points out that the computation of LOWMEM_PAGES causes a signed integer overflow on 32-bit x86: arch/x86/kernel/head32.c:83:20: error: signed shift result (0x100000000) requires 34 bits to represent, but 'int' only has 32 bits [-Werror,-Wshift-overflow] (PAGE_TABLE_SIZE(LOWMEM_PAGES) << PAGE_SHIFT); ^~~~~~~~~~~~ arch/x86/include/asm/pgtable_32.h:109:27: note: expanded from macro 'LOWMEM_PAGES' #define LOWMEM_PAGES ((((2<<31) - __PAGE_OFFSET) >> PAGE_SHIFT)) ~^ ~~ arch/x86/include/asm/pgtable_32.h:98:34: note: expanded from macro 'PAGE_TABLE_SIZE' #define PAGE_TABLE_SIZE(pages) ((pages) / PTRS_PER_PGD) Use the _ULL() macro to make it a 64-bit constant. Fixes: 1e620f9b ("x86/boot/32: Convert the 32-bit pgtable setup code from assembly to C") Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit 5c4b4608 ] netem runs skb_orphan_partial() which "disconnects" the skb from normal TCP write memory accounting. We should not adjust sk->sk_wmem_alloc on the fallback path for such skbs. Fixes: e8f69799 ("net/tls: Add generic NIC offload infrastructure") Signed-off-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
Dirk van der Merwe <dirk.vandermerwe@netronome.com> Signed-off-by:
-
Wen Yang authored
[ Upstream commit faf5577f ] The phy_dn variable is still being used in of_phy_connect() after the of_node_put() call, which may result in use-after-free. Fixes: 1dd2d06c ("net: Rework pasemi_mac driver to use of_mdio infrastructure") Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: "David S. Miller" <davem@davemloft.net> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: netdev@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
David Disseldorp authored
[ Upstream commit 71880728 ] The vxattr value incorrectly places a "09" prefix to the nanoseconds field, instead of providing it as a zero-pad width specifier after '%'. Fixes: 3489b42a ("ceph: fix three bugs, two in ceph_vxattrcb_file_layout()") Link: https://tracker.ceph.com/issues/39943Signed-off-by:
David Disseldorp <ddiss@suse.de> Reviewed-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
-
Hou Zhiqiang authored
[ Upstream commit ccd34dac ] In program_ib/ob_windows() check the window index from the function parameter instead of the total number of initialized windows to determine if the specified window is valid. Fixes: 9af6bcb1 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver") Signed-off-by:
Hou Zhiqiang <Zhiqiang.Hou@nxp.com> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by:
Minghuan Lian <Minghuan.Lian@nxp.com> Reviewed-by:
Subrahmanya Lingappa <l.subrahmanya@mobiveil.co.in> Signed-off-by:
-
Hou Zhiqiang authored
[ Upstream commit cbd50b3c ] Current check for devfn number in mobiveil_pci_valid_device() is wrong in that it flags as invalid functions present in PCI device 0 in the root bus while it is perfectly valid to access all functions in PCI device 0 in the root bus. Update the check in mobiveil_pci_valid_device() to fix the issue. Fixes: 9af6bcb1 ("PCI: mobiveil: Add Mobiveil PCIe Host Bridge IP driver") Signed-off-by:
-
Hou Zhiqiang authored
[ Upstream commit a131fb63 ] The Mobiveil internal MSI controller requires separate target addresses, one per MSI vector; this is clearly incompatible with the Multiple MSI feature, which requires the same target address for all vectors requested by an endpoint (ie the Message Address field in the MSI Capability structure), so the multi MSI feature is clearly not supported by the host controller driver. Remove the flag MSI_FLAG_MULTI_PCI_MSI and with it multi MSI support, fixing the misconfiguration. Fixes: 1e913e58 ("PCI: mobiveil: Add MSI support") Signed-off-by:
-
Xi Wang authored
[ Upstream commit ec5bc2cc ] When smmu is enable, if execute the perftest command and then use 'kill -9' to exit, follow this operation repeatedly, the kernel will have a high probability to print the following smmu event: arm-smmu-v3 arm-smmu-v3.1.auto: event 0x10 received: arm-smmu-v3 arm-smmu-v3.1.auto: 0x00007d0000000010 arm-smmu-v3 arm-smmu-v3.1.auto: 0x0000020900000080 arm-smmu-v3 arm-smmu-v3.1.auto: 0x00000000f47cf000 arm-smmu-v3 arm-smmu-v3.1.auto: 0x00000000f47cf000 This is because the hw will periodically refresh the qpc cache until the next reset. This patch fixed it by removing the action that release qpc memory in the 'hns_roce_qp_free' function. Fixes: 9a443537 ("IB/hns: Add driver files for hns RoCE driver") Signed-off-by:
Xi Wang <wangxi11@huawei.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
Eddie James authored
[ Upstream commit 7ce98fb6 ] SBE fifo operations should be allowed while the SBE is in any of the "IPL" states. Operations should succeed in this state. Fixes: 9f4a8a2d fsi/sbefifo: Add driver for the SBE FIFO Reviewed-by:
Joel Stanley <joel@jms.id.au> Tested-by:
Alistair Popple <alistair@popple.id.au> Signed-off-by:
Eddie James <eajames@linux.ibm.com> Link: https://lore.kernel.org/r/1561575415-3282-1-git-send-email-eajames@linux.ibm.comSigned-off-by:
-
Arnd Bergmann authored
[ Upstream commit 9dea44c9 ] devm_ioremap_resource() does not currently take 'const' arguments, which results in a warning from the first driver trying to do it anyway: drivers/gpio/gpio-amd-fch.c: In function 'amd_fch_gpio_probe': drivers/gpio/gpio-amd-fch.c:171:49: error: passing argument 2 of 'devm_ioremap_resource' discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers] priv->base = devm_ioremap_resource(&pdev->dev, &amd_fch_gpio_iores); ^~~~~~~~~~~~~~~~~~~ Change the prototype to allow it, as there is no real reason not to. Fixes: 9bb2e0452508 ("gpio: amd: Make resource struct const") Signed-off-by:
Enrico Weigelt <info@metux.net> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jeremy Kerr authored
[ Upstream commit 371975b0 ] Change d1dcd678 re-worked the struct fsi_slave initialisation in fsi_slave_init, but introduced a few inconsitencies: the slave->dev is now registered through cdev_device_add, but we may kfree() the device out from underneath the cdev registration. We may also leave an IDA allocated. This change fixes the error paths, so that we kfree() only before the device is registered with the core code. We also move the smode write to before we start creating proper devices, as it's the most likely to fail. We also remove the IDA-allocated minor on error, and properly clean up the of_node. Fixes: d1dcd678 ("fsi: Add cfam char devices") Reported-by:
Lei YU <mine260309@gmail.com> Tested-by:
John Wang <wangzqbj@inspur.com> Signed-off-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit c95b7595 ] In general, it is not correct to call pm_generic_suspend(), pm_generic_suspend_late() and pm_generic_suspend_noirq() during the hibernation's "poweroff" transition, because device drivers may provide special callbacks to be invoked then and the wrappers in question cause system suspend callbacks to be run. Unfortunately, that happens in the ACPI PM domain and ACPI LPSS. To address this potential issue, introduce "poweroff" callbacks for the ACPI PM and LPSS that will use pm_generic_poweroff(), pm_generic_poweroff_late() and pm_generic_poweroff_noirq() as appropriate. Fixes: 05087360 (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 3cd7957e ] First, after a previous change causing all runtime-suspended devices in the ACPI PM domain (and ACPI LPSS devices) to be resumed before creating a snapshot image of memory during hibernation, it is not necessary to worry about the case in which them might be left in runtime-suspend any more, so get rid of the code related to that from ACPI PM domain and ACPI LPSS hibernation callbacks. Second, it is not correct to use pm_generic_resume_early() and acpi_subsys_resume_noirq() in hibernation "restore" callbacks (which currently happens in the ACPI PM domain and ACPI LPSS), so introduce proper _restore_late and _restore_noirq callbacks for the ACPI PM domain and ACPI LPSS. Fixes: 05087360 (ACPI / PM: Take SMART_SUSPEND driver flag into account) Signed-off-by:
-
Rafael J. Wysocki authored
[ Upstream commit 501debd4 ] Both the PCI bus type and the ACPI PM domain avoid resuming runtime-suspended devices with DPM_FLAG_SMART_SUSPEND set during hibernation (before creating the snapshot image of system memory), but that turns out to be a mistake. It leads to functional issues and adds complexity that's hard to justify. For this reason, resume all runtime-suspended PCI devices and all devices in the ACPI PM domains before creating a snapshot image of system memory during hibernation. Fixes: 05087360 (ACPI / PM: Take SMART_SUSPEND driver flag into account) Fixes: c4b65157 (PCI / PM: Take SMART_SUSPEND driver flag into account) Link: https://lore.kernel.org/linux-acpi/917d4399-2e22-67b1-9d54-808561f9083f@uwyo.edu/T/#maf065fe6e4974f2a9d79f332ab99dfaba635f64cReported-by:
Robert R. Howell <RHowell@uwyo.edu> Tested-by:
-
Jouni Malinen authored
[ Upstream commit bebe4681 ] The conversion of UML to use epoll based IRQ controller claimed that clone_one_chan() can safely call um_free_irq() while starting to ignore the delay_free_irq parameter that explicitly noted that the IRQ cannot be freed because this is being called from chan_interrupt(). This resulted in free_irq() getting called in interrupt context ("Trying to free IRQ 6 from IRQ context!"). Fix this by restoring previously used delay_free_irq processing. Fixes: ff6a1798 ("Epoll based IRQ controller") Signed-off-by:
Jouni Malinen <j@w1.fi> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Chuck Lever authored
[ Upstream commit 2d0abe36 ] Dereference wr->next /before/ the memory backing wr has been released. This issue was found by code inspection. It is not expected to be a significant problem because it is in an error path that is almost never executed. Fixes: 7c8d9e7c ("xprtrdma: Move Receive posting to ... ") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
David Howells authored
[ Upstream commit 3427beb6 ] With gcc 4.1: net/rxrpc/output.c: In function ‘rxrpc_send_data_packet’: net/rxrpc/output.c:338: warning: ‘ret’ may be used uninitialized in this function Indeed, if the first jump to the send_fragmentable label is made, and the address family is not handled in the switch() statement, ret will be used uninitialized. Fix this by BUG()'ing as is done in other places in rxrpc where internal support for future address families will need adding. It should not be possible to reach this normally as the address families are checked up-front. Fixes: 5a924b89 ("rxrpc: Don't store the rxrpc header in the Tx queue sk_buffs") Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
David Howells <dhowells@redhat.com> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 02f36911 ] ida instances allocate some internal memory for ->free_bitmap in addition to the base 'struct ida'. Use ida_destroy() to release that memory at module_exit(). Fixes: 4b45efe8 ("mfd: Add support for Intel Sunrisepoint LPSS devices") Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Kevin Mitchell authored
[ Upstream commit 3ddbe913 ] Make it safe to call iommu_disable during early init error conditions before mmio_base is set, but after the struct amd_iommu has been added to the amd_iommu_list. For example, this happens if firmware fails to fill in mmio_phys in the ACPI table leading to a NULL pointer dereference in iommu_feature_disable. Fixes: 2c0ae172 ('iommu/amd: Convert iommu initialization to state machine') Signed-off-by:
Kevin Mitchell <kevmitch@arista.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Michael Chan authored
[ Upstream commit 4ca5fa39 ] Some firmware versions do not support this so use the silent variant to send the message to firmware to suppress the harmless error. This error message is unnecessarily alarming the user. Fixes: afdc8a84 ("bnxt_en: Add DCBNL DSCP application protocol support.") Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
Michael Chan authored
[ Upstream commit d27e2ca1 ] After ethtool loopback packet tests, we re-open the nic for the next IRQ test. If the open fails, we must not proceed with the IRQ test or we will crash with NULL pointer dereference. Fix it by checking the bnxt_open_nic() return code before proceeding. Reported-by:
Somasundaram Krishnasamy <somasundaram.krishnasamy@oracle.com> Fixes: 67fea463 ("bnxt_en: Add interrupt test to ethtool -t selftest.") Signed-off-by:
-
Andrea Arcangeli authored
[ Upstream commit 1bf4580e ] Commit 5eed6f1d ("fork,memcg: fix crash in free_thread_stack on memcg charge fail") corrected two instances, but there was a third instance of this bug. Without setting tsk->stack, if memcg_charge_kernel_stack fails, it'll execute free_thread_stack() on a dangling pointer. Enterprise kernels are compiled with VMAP_STACK=y so this isn't critical, but custom VMAP_STACK=n builds should have some performance advantage, with the drawback of risking to fail fork because compaction didn't succeed. So as long as VMAP_STACK=n is a supported option it's worth fixing it upstream. Link: http://lkml.kernel.org/r/20190619011450.28048-1-aarcange@redhat.com Fixes: 9b6f7e16 ("mm: rework memcg kernel stack accounting") Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Reviewed-by:
Rik van Riel <riel@surriel.com> Acked-by:
Roman Gushchin <guro@fb.com> Acked-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Matthias Kaehlcke authored
[ Upstream commit 73fbfc49 ] With commit 88ba95be ("backlight: pwm_bl: Compute brightness of LED linearly to human eye") the number of set bits (aka hweight()) in the PWM period is used in the heuristic to determine the number of brightness levels, when the brightness table isn't specified in the DT. The number of set bits doesn't provide a reliable clue about the length of the period, instead change the heuristic to: nlevels = period / fls(period) Also limit the maximum number of brightness levels to 4096 to avoid excessively large tables. With this the number of levels increases monotonically with the PWM period, until the maximum of 4096 levels is reached: period (ns) # levels 100 16 500 62 1000 111 5000 416 10000 769 50000 3333 100000 4096 Fixes: 88ba95be ("backlight: pwm_bl: Compute brightness of LED linearly to human eye") Signed-off-by:
Matthias Kaehlcke <mka@chromium.org> Acked-by:
Daniel Thompson <daniel.thompson@linaro.org> Tested-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit 6c6874f4 ] cgroup code tries to use argv[0] as the cgroup path, but if it fails uses argv[1] to report errors. Fixes: 5ccda64d ("bpftool: implement cgroup bpf operations") Signed-off-by:
Quentin Monnet <quentin.monnet@netronome.com> Acked-by:
-
