- 12 Jul, 2022 40 commits
-
-
Peng Fan authored
[ Upstream commit b838582a ] 0x19 is not a valid setting. According to RM bit layout, BIT3 and BIT0 are reserved. 8 7 6 5 4 3 2 1 0 PE HYS PUE ODE FSEL X DSE X Correct setting with PE PUE set, DSE set to 0. Fixes: 50d336b1 ("arm64: dts: imx8mp-evk: Add GPIO LED support") Signed-off-by:
Peng Fan <peng.fan@nxp.com> Reviewed-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Signed-off-by:
Shawn Guo <shawnguo@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Sherry Sun authored
[ Upstream commit 2d4fb72b ] According to the IOMUXC_SW_PAD_CTL_PAD_UART2_RXD/TXD register define in imx8mp RM, bit0 and bit3 are reserved, and the uart2 rx/tx pin should enable the pull up, so need to set bit8 to 1. The original pinctl value 0x49 is incorrect and needs to be changed to 0x140, same as uart1 and uart3. Fixes: 9e847693 ("arm64: dts: freescale: Add i.MX8MP EVK board support") Reviewed-by:
Haibo Chen <haibo.chen@nxp.com> Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Signed-off-by:
-
Peng Fan authored
[ Upstream commit 01785f1f ] According to RM bit layout, BIT3 and BIT0 are reserved. 8 7 6 5 4 3 2 1 0 PE HYS PUE ODE FSEL X DSE X Not set reserved bit. Fixes: 9e847693 ("arm64: dts: freescale: Add i.MX8MP EVK board support") Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit b10ef5f2 ] Currently, when booting Linux on a imx28-evk board there is no display activity. Enable CONFIG_FB which is nowadays required for CONFIG_DRM_PANEL_LVDS, CONFIG_DRM_PANEL_SIMPLE, CONFIG_DRM_PANEL_SEIKO_43WVF1G, CONFIG_FB_MODE_HELPERS, CONFIG_BACKLIGHT_PWM, CONFIG_BACKLIGHT_GPIO, CONFIG_FRAMEBUFFER_CONSOLE, CONFIG_LOGO, CONFIG_FONTS, CONFIG_FONT_8x8 and CONFIG_FONT_8x16. Based on commit c5446748 ("ARM: imx_v6_v7_defconfig: enable fb"). Fixes: f611b1e7 ("drm: Avoid circular dependencies for CONFIG_FB") Signed-off-by:
Fabio Estevam <festevam@denx.de> Signed-off-by:
-
Dmitry Baryshkov authored
[ Upstream commit 3ba500de ] It was noticed that on sdm845 after an MDSS suspend/resume cycle the driver can not read HW_REV registers properly (they will return 0 instead). Chaning the "iface" clock from <&gcc GCC_DISP_AHB_CLK> to <&dispcc DISP_CC_MDSS_AHB_CLK> fixes the issue. Fixes: 08c2a076 ("arm64: dts: qcom: sdm845: Add dpu to sdm845 dts file") Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20220531124735.1165582-1-dmitry.baryshkov@linaro.org Signed-off-by:
-
Konrad Dybcio authored
[ Upstream commit 47bf59c4 ] CPU6 and CPU7 were mistakengly pointing to CPU5 reg. Fix it. Fixes: 02d8091b ("arm64: dts: qcom: msm8994: Add a proper CPU map") Signed-off-by:
Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by:
-
Vladimir Zapolskiy authored
[ Upstream commit de9b3d96 ] All interconnect device tree nodes on sm8450 are 2-cells, however in UFS node they are handled as 1-cells, fix it. Fixes: aa2d0bf0 ("arm64: dts: qcom: sm8450: add interconnect nodes") Signed-off-by:
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reviewed-by:
Vinod Koul <vkoul@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit ca7ab1dc ] Commit 288fad2f ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information") modified the PCM path only, but left the compressed data patch using an obsolete option. Move the functionality in a helper that can be called for both PCM and compressed data. Reviewed-by:
Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Fixes: 288fad2f ("ASoC: SOF: Intel: hda: add quirks for HDAudio DMA position information") Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Signed-off-by:
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://lore.kernel.org/r/20220616201953.130876-1-pierre-louis.bossart@linux.intel.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit c2d1aec3 ] Move the size checks prior to allocating memory as these checks do not need the data to be allocated and in case of an error we would not need to free the allocation. The max size must not be less than the size of struct sof_ipc_ctrl_data + struct sof_abi_hdr as the ABI header needs to be present under all circumstances. The check was incorrectly used or between the two size checks. Fixes: b5cee8fe ("ASoC: SOF: topology: Make control parsing IPC agnostic") Signed-off-by:
Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220610084735.19397-1-peter.ujfalusi@linux.intel.com Signed-off-by:
-
Pierre-Louis Bossart authored
[ Upstream commit 40737057 ] The .set_jack_detect() codec component callback is invoked during card registration, which happens when the machine driver is probed. The issue is that this callback can race with the bus suspend/resume, and IO timeouts can happen. This can be reproduced very easily if the machine driver is 'blacklisted' and manually probed after the bus suspends. The bus and codec need to be re-initialized using pm_runtime helpers. Previous contributions tried to make sure accesses to the bus during the .set_jack_detect() component callback only happen when the bus is active. This was done by changing the regcache status on a component remove. This is however a layering violation, the regcache status should only be modified on device probe, suspend and resume. The component probe/remove should not modify how the device regcache is handled. This solution also didn't handle all the possible race conditions, and the RT700 headset codec was not handled. This patch tries to resume the codec device before handling the jack initializations. In case the codec has not yet been initialized, pm_runtime may not be enabled yet, so we don't squelch the -EACCES error code and only stop the jack information. When the codec reports as attached, the jack initialization will proceed as usual. BugLink: https://github.com/thesofproject/linux/issues/3643 Fixes: 7ad4d237 ('ASoC: rt711-sdca: Add RT711 SDCA vendor-specific driver') Fixes: 899b1254 ('ASoC: rt711: add snd_soc_component remove callback') Signed-off-by:
Rander Wang <rander.wang@intel.com> Reviewed-by:
-
Charles Keepax authored
[ Upstream commit 3e50a500 ] The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied. Signed-off-by:
Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://lore.kernel.org/r/20220504170905.332415-32-ckeepax@opensource.cirrus.com Signed-off-by:
-
Charles Keepax authored
[ Upstream commit 33f06bea ] The endianness flag is used on the CODEC side to specify an ambivalence to endian, typically because it is lost over the hardware link. This device receives audio over a SoundWire DAI and as such should have endianness applied. Signed-off-by:
-
Paul E. McKenney authored
[ Upstream commit 8ed00760 ] Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct(). Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Signed-off-by:
-
Samuel Holland authored
[ Upstream commit aaefa292 ] The other NAND pins on Port C use the "nand0" function name. "nand0" also matches all of the other Allwinner SoCs. Fixes: 4730f33f ("pinctrl: sunxi: add allwinner A83T PIO controller support") Signed-off-by:
Samuel Holland <samuel@sholland.org> Acked-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/r/20220526024956.49500-1-samuel@sholland.org Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Miaoqian Lin authored
[ Upstream commit 34d2cd3f ] of_find_compatible_node() returns a node pointer with refcount incremented, we should use of_node_put() on it when done. Add missing of_node_put() to avoid refcount leak. Fixes: d850f3e5 ("ARM: meson: Add SMP bringup code for Meson8 and Meson8b") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
Neil Armstrong <narmstrong@baylibre.com> Link: https://lore.kernel.org/r/20220512021611.47921-1-linmq006@gmail.com Signed-off-by:
-
Christian Marangi authored
commit 386228c6 upstream. It was discovered that the Documentation lacks of a fundamental detail on how to correctly change the MAX_FRAME_SIZE of the switch. In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the switch panics and cease to send any packet. This cause the mgmt ethernet system to not receive any packet (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. To correctly handle this, turn off the cpu ports before changing the MAX_FRAME_SIZE and turn on again after the value is applied. Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks") Cc: stable@vger.kernel.org Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20220621151122.10220-1-ansuelsmth@gmail.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason A. Donenfeld authored
commit 88750282 upstream. The platform device for the rng must be created much later in boot. Otherwise it tries to connect to a parent that doesn't yet exist, resulting in this splat: [ 0.000478] kobject: '(null)' ((____ptrval____)): is not initialized, yet kobject_get() is being called. [ 0.002925] [c000000002a0fb30] [c00000000073b0bc] kobject_get+0x8c/0x100 (unreliable) [ 0.003071] [c000000002a0fba0] [c00000000087e464] device_add+0xf4/0xb00 [ 0.003194] [c000000002a0fc80] [c000000000a7f6e4] of_device_add+0x64/0x80 [ 0.003321] [c000000002a0fcb0] [c000000000a800d0] of_platform_device_create_pdata+0xd0/0x1b0 [ 0.003476] [c000000002a0fd00] [c00000000201fa44] pnv_get_random_long_early+0x240/0x2e4 [ 0.003623] [c000000002a0fe20] [c000000002060c38] random_init+0xc0/0x214 This patch fixes the issue by doing the platform device creation inside of machine_subsys_initcall. Fixes: f3eac426 ("powerpc/powernv: wire up rng during setup_arch") Cc: stable@vger.kernel.org Reported-by:
Sachin Sant <sachinp@linux.ibm.com> Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Tested-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20220630121654.1939181-1-Jason@zx2c4.com Signed-off-by:
-
Yue Hu authored
commit bf17455b upstream. After waiting for the volume to complete the acquisition with timeout, the if condition under which potential volume collision occurs should be acquire the volume is still pending rather than not pending so that we will continue to wait until the pending flag is cleared. Also, use the existing test pending wrapper directly instead of test_bit(). Fixes: 62ab6335 ("fscache: Implement volume registration") Signed-off-by:
Yue Hu <huyue2@coolpad.com> Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Gao Xiang <hsiangkao@linux.alibaba.com> Reviewed-by:
Jeffle Xu <jefflexu@linux.alibaba.com> Reviewed-by:
Jeff Layton <jlayton@kernel.org> Link: https://listman.redhat.com/archives/linux-cachefs/2022-May/006918.html Signed-off-by:
-
David Howells authored
commit 85e4ea10 upstream. If an NFS file is opened for writing and closed, fscache_invalidate() will be asked to invalidate the file - however, if the cookie is in the LOOKING_UP state (or the CREATING state), then request to invalidate doesn't get recorded for fscache_cookie_state_machine() to do something with. Fix this by making __fscache_invalidate() set a flag if it sees the cookie is in the LOOKING_UP state to indicate that we need to go to invalidation. Note that this requires a count on the n_accesses counter for the state machine, which that will release when it's done. fscache_cookie_state_machine() then shifts to the INVALIDATING state if it sees the flag. Without this, an nfs file can get corrupted if it gets modified locally and then read locally as the cache contents may not get updated. Fixes: d24af13e ("fscache: Implement cookie invalidation") Reported-by:
Max Kellermann <mk@cm4all.com> Signed-off-by:
-
Hsin-Yi Wang authored
commit 3663a2fb upstream. If CONFIG_OF is not enabled, default of_get_display_timing() returns an errno, so include the header. Fixes: 422b67e0 ("videomode: provide dummy inline functions for !CONFIG_OF") Suggested-by:
Stephen Boyd <swboyd@chromium.org> Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Helge Deller <deller@gmx.de> Signed-off-by:
-
Dan Williams authored
commit f50974ee upstream. In the CONFIG_MEMREGION=n case, memregion_free() is meant to be a static inline. 0day reports: In file included from drivers/cxl/core/port.c:4: include/linux/memregion.h:19:6: warning: no previous prototype for function 'memregion_free' [-Wmissing-prototypes] Mark memregion_free() static. Fixes: 33dd7075 ("lib: Uplevel the pmem "region" ida to a global allocator") Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Alison Schofield <alison.schofield@intel.com> Link: https://lore.kernel.org/r/165601455171.4042645.3350844271068713515.stgit@dwillia2-xfh Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Rafael J. Wysocki authored
commit 88737106 upstream. Because pm_runtime_get_suppliers() bumps up the rpm_active counter of each device link to a supplier of the given device in addition to bumping up the supplier's PM-runtime usage counter, a runtime suspend of the consumer device may case the latter to go down to 0 when pm_runtime_put_suppliers() is running on a remote CPU. If that happens after pm_runtime_put_suppliers() has released power.lock for the consumer device, and a runtime resume of that device takes place immediately after it, before pm_runtime_put() is called for the supplier, that pm_runtime_put() call may cause the supplier to be suspended even though the consumer is active. To prevent that from happening, modify pm_runtime_get_suppliers() to call pm_runtime_get_sync() for the given device's suppliers without touching the rpm_active counters of the involved device links Accordingly, modify pm_runtime_put_suppliers() ...
-
Rafael J. Wysocki authored
commit 07358194 upstream. Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its callers take care of triggering a runtime-suspend of the supplier device as needed. No expected functional impact. Suggested-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by:
-
Helge Deller authored
commit e64242ca upstream. We need to prevent that users configure a screen size which is smaller than the currently selected font size. Otherwise rendering chars on the screen will access memory outside the graphics memory region. This patch adds a new function fbcon_modechange_possible() which implements this check and which later may be extended with other checks if necessary. The new function is called from the FBIOPUT_VSCREENINFO ioctl handler in fbmem.c, which will return -EINVAL if userspace asked for a too small screen size. Signed-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Cc: stable@vger.kernel.org # v5.4+ Signed-off-by:
-
Helge Deller authored
commit 65a01e60 upstream. Prevent that users set a font size which is bigger than the physical screen. It's unlikely this may happen (because screens are usually much larger than the fonts and each font char is limited to 32x32 pixels), but it may happen on smaller screens/LCD displays. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Helge Deller authored
commit 6c11df58 upstream. Verify that the fbdev or drm driver correctly adjusted the virtual screen sizes. On failure report the failing driver and reject the screen size change. Signed-off-by:
-
Guiling Deng authored
commit 955f0476 upstream. Image.dx gets wrong value because of missing '()'. If xres == logo->width and n == 1, image.dx = -16. Signed-off-by:
Guiling Deng <greens9@163.com> Fixes: 3d8b1933 ("fbdev: fbmem: add config option to center the bootup logo") Cc: stable@vger.kernel.org # v5.0+ Signed-off-by:
-
Jonathan Cameron authored
commit db9a3a35 upstream. The device is created, and then there is a check if a driver succesfully bound to it. In event of failing the bind (e.g. failure in cxl_port_probe()) the device is left registered. When a bus rescan later occurs, fresh devices are created leading to a multiple device representing the same underlying hardware. Bad things may follow and at very least we have far too many devices. Fix by ensuring autoremove is registered if the device create succeeds, but doesn't depend on sucessful binding to a driver. Bug was observed as side effect of incorrect ownership in [PATCH v9 6/9] cxl/port: Read CDAT table but will result from any failure to in cxl_port_probe(). Fixes: 8dd2bc0f ("cxl/mem: Add the cxl_mem driver") Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Ira Weiny <ira.weiny@intel.com> Link: https://lore.kernel.org/r/20220609134519.11668-1-Jonathan.Cameron@...
-
Alison Schofield authored
commit 8a664875 upstream. CXL specification defines these as little endian. Fixes: 60b8f172 ("cxl/pmem: Translate NVDIMM label commands to CXL label commands") Reported-by:
-
Lu Baolu authored
commit 4140d77a upstream. The IOMMU driver shares the pasid table for PCI alias devices. When the RID2PASID entry of the shared pasid table has been filled by the first device, the subsequent device will encounter the "DMAR: Setup RID2PASID failed" failure as the pasid entry has already been marked as present. As the result, the IOMMU probing process will be aborted. On the contrary, when any alias device is hot-removed from the system, for example, by writing to /sys/bus/pci/devices/.../remove, the shared RID2PASID will be cleared without any notifications to other devices. As the result, any DMAs from those rest devices are blocked. Sharing pasid table among PCI alias devices could save two memory pages for devices underneath the PCIe-to-PCI bridges. Anyway, considering that those devices are rare on modern platforms that support VT-d in scalable mode and the saved memory is negligible, it's reasonable to remove this par...
-
Yian Chen authored
commit 316f92a7 upstream. Notifier calling chain uses priority to determine the execution order of the notifiers or listeners registered to the chain. PCI bus device hot add utilizes the notification mechanism. The current code sets low priority (INT_MIN) to Intel dmar_pci_bus_notifier and postpones DMAR decoding after adding new device into IOMMU. The result is that struct device pointer cannot be found in DRHD search for the new device's DMAR/IOMMU. Subsequently, the device is put under the "catch-all" IOMMU instead of the correct one. This could cause system hang when device TLB invalidation is sent to the wrong IOMMU. Invalidation timeout error and hard lockup have been observed and data inconsistency/crush may occur as well. This patch fixes the issue by setting a positive priority(1) for dmar_pci_bus_notifier while the priority of IOMMU bus notifier uses the default value(0), therefore DMAR decoding will be in advance of DRHD search for a new device to find the correct IOMMU. Following is a 2-step example that triggers the bug by simulating PCI device hot add behavior in Intel Sapphire Rapids server. echo 1 > /sys/bus/pci/devices/0000:6a:01.0/remove echo 1 > /sys/bus/pci/rescan Fixes: 59ce0515 ("iommu/vt-d: Update DRHD/RMRR/ATSR device scope") Cc: stable@vger.kernel.org # v3.15+ Reported-by:
Zhang, Bernice <bernice.zhang@intel.com> Signed-off-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
Yian Chen <yian.chen@intel.com> Link: https://lore.kernel.org/r/20220521002115.1624069-1-yian.chen@intel.com Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
-
Joerg Roedel authored
commit c51b8f85 upstream. The IOMMU mailing list has moved to iommu@lists.linux.dev and the old list should bounce by now. Remove it from the MAINTAINERS file. Cc: stable@vger.kernel.org Signed-off-by:
-
Srinivas Kandagatla authored
commit 58136d93 upstream. prepare callback can be called multiple times, so unprepare the stream if its already prepared. Without this DSP is not happy to setting the params on a already prepared graph. Fixes: 9b4fe0f1 ("ASoC: qdsp6: audioreach: add q6apm-dai support") Reported-by:
Srinivasa Rao Mandadapu <quic_srivasam@quicinc.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220610144818.511797-1-srinivas.kandagatla@linaro.org Signed-off-by:
-
Duy Nguyen authored
commit 374e11f1 upstream. On R-Car V3U, this driver should use suitable register offset instead of other SoCs' one. Otherwise, data transmission failed on R-Car V3U. Fixes: 45721c40 ("can: rcar_canfd: Add support for r8a779a0 SoC") Link: https://lore.kernel.org/all/20220704074611.957191-1-yoshihiro.shimoda.uh@renesas.com Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Duy Nguyen <duy.nguyen.rh@renesas.com> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Marc Kleine-Budde authored
commit 1c0e78a2 upstream. In mcp251xfd_register_get_dev_id() the device ID register is read with handcrafted SPI transfers. As all registers, this register is in little endian. Further it is not naturally aligned in struct mcp251xfd_map_buf_nocrc::data. However after the transfer the register content is converted from big endian to CPU endianness not taking care of being unaligned. Fix the conversion by converting from little endian to CPU endianness taking the unaligned source into account. Side note: So far the register content is 0x0 on all mcp251xfd compatible chips, and is only used for an informative printk. Link: https://lore.kernel.org/all/20220627092859.809042-1-mkl@pengutronix.de Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
-
Marc Kleine-Budde authored
commit 0ff32bfa upstream. The device ID register is 32 bits wide. The driver uses incorrectly the size of a pointer to a u32 to calculate the length of the SPI transfer. This results in a read of 2 registers on 64 bit platforms. This is no problem on the Linux side, as the RX buffer of the SPI transfer is large enough. In the mpc251xfd chip this results in the read of an undocumented register. So far no problems were observed. Fix the length of the SPI transfer to read the device ID register only. Link: https://lore.kernel.org/all/20220616094914.244440-1-mkl@pengutronix.de Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Reported-by:
-
Hangbin Liu authored
commit d28b25a6 upstream. Since commit 8fffa0e3 ("selftests/bpf: Normalize XDP section names in selftests") the xdp_dummy.o's section name has changed to xdp. But some tests are still using "section xdp_dummy", which make the tests failed. Fix them by updating to the new section name. Fixes: 8fffa0e3 ("selftests/bpf: Normalize XDP section names in selftests") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/r/20220630062228.3453016-1-liuhangbin@gmail.com Signed-off-by:
-
Pablo Neira Ayuso authored
commit 7e6bc1f6 upstream. Make sure element data type and length do not mismatch the one specified by the set declaration. Fixes: 7d740264 ("netfilter: nf_tables: variable sized set element keys / data") Reported-by:
Hugues ANGUELKOV <hanguelkov@randorisec.fr> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Pablo Neira Ayuso authored
commit 9827a0e6 upstream. New elements that reside in the clone are not released in case that the transaction is aborted. [16302.231754] ------------[ cut here ]------------ [16302.231756] WARNING: CPU: 0 PID: 100509 at net/netfilter/nf_tables_api.c:1864 nf_tables_chain_destroy+0x26/0x127 [nf_tables] [...] [16302.231882] CPU: 0 PID: 100509 Comm: nft Tainted: G W 5.19.0-rc3+ #155 [...] [16302.231887] RIP: 0010:nf_tables_chain_destroy+0x26/0x127 [nf_tables] [16302.231899] Code: f3 fe ff ff 41 55 41 54 55 53 48 8b 6f 10 48 89 fb 48 c7 c7 82 96 d9 a0 8b 55 50 48 8b 75 58 e8 de f5 92 e0 83 7d 50 00 74 09 <0f> 0b 5b 5d 41 5c 41 5d c3 4c 8b 65 00 48 8b 7d 08 49 39 fc 74 05 [...] [16302.231917] Call Trace: [16302.231919] <TASK> [16302.231921] __nf_tables_abort.cold+0x23/0x28 [nf_tables] [16302.231934] nf_tables_abort+0x30/0x50 [nf_tables] [16302.231946] nfnetlink_rcv_batch+0x41a/0x840 [nfnetlink] [16302.231952] ? __nla_validate_parse+0x48/0x190 [16302.231959] nfnetlink_rcv+0x110/0x129 [nfnetlink] [16302.231963] netlink_unicast+0x211/0x340 [16302.231969] netlink_sendmsg+0x21e/0x460 Add nft_set_pipapo_match_destroy() helper function to release the elements in the lookup tables. Stefano Brivio says: "We additionally look for elements pointers in the cloned matching data if priv->dirty is set, because that means that cloned data might point to additional elements we did not commit to the working copy yet (such as the abort path case, but perhaps not limited to it)." Fixes: 3c4287f6 ("nf_tables: Add set type for arbitrary concatenation of ranges") Reviewed-by:
Stefano Brivio <sbrivio@redhat.com> Signed-off-by:
-
Michael Walle authored
commit e6fa930f upstream. Instead of counting the child nodes in the device tree, hardcode the number of ports in the driver itself. The counting won't work at all if an ethernet port is marked as disabled, e.g. because it is not connected on the board at all. It turns out that the LAN9662 and LAN9668 use the same switching IP with the same synthesis parameters. The only difference is that the output ports are not connected. Thus, we can just hardcode the number of physical ports to 8. Fixes: db8bcaad ("net: lan966x: add the basic lan966x driver") Signed-off-by:
Michael Walle <michael@walle.cc> Reviewed-by:
Horatiu Vultur <horatiu.vultur@microchip.com> Link: https://lore.kernel.org/r/20220704153654.1167886-1-michael@walle.cc Signed-off-by:
-
