summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-09-30spi: bcm63xx: Enable module autoloadingLiao Chen
[ Upstream commit 709df70a20e990d262c473ad9899314039e8ec82 ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Liao Chen <liaochen4@huawei.com> Link: https://patch.msgid.link/20240831094231.795024-1-liaochen4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30drm: komeda: Fix an issue related to normalized zposhongchi.peng
[ Upstream commit 258905cb9a6414be5c9ca4aa20ef855f8dc894d4 ] We use komeda_crtc_normalize_zpos to normalize zpos of affected planes to their blending zorder in CU. If there's only one slave plane in affected planes and its layer_split property is enabled, order++ for its split layer, so that when calculating the normalized_zpos of master planes, the split layer of the slave plane is included, but the max_slave_zorder does not include the split layer and keep zero because there's only one slave plane in affacted planes, although we actually use two slave layers in this commit. In most cases, this bug does not result in a commit failure, but assume the following situation: slave_layer 0: zpos = 0, layer split enabled, normalized_zpos = 0;(use slave_layer 2 as its split layer) master_layer 0: zpos = 2, layer_split enabled, normalized_zpos = 2;(use master_layer 2 as its split layer) master_layer 1: zpos = 4, normalized_zpos = 4; master_layer 3: zpos = 5, normalized_zpos = 5; kcrtc_st->max_slave_zorder = 0; When we use master_layer 3 as a input of CU in function komeda_compiz_set_input and check it with function komeda_component_check_input, the parameter idx is equal to normailzed_zpos minus max_slave_zorder, the value of idx is 5 and is euqal to CU's max_active_inputs, so that komeda_component_check_input returns a -EINVAL value. To fix the bug described above, when calculating the max_slave_zorder with the layer_split enabled, count the split layer in this calculation directly. Signed-off-by: hongchi.peng <hongchi.peng@siengine.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240826024517.3739-1-hongchi.peng@siengine.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30spi: spidev: Add an entry for elgin,jg10309-01Fabio Estevam
[ Upstream commit 5f3eee1eef5d0edd23d8ac0974f56283649a1512 ] The rv1108-elgin-r1 board has an LCD controlled via SPI in userspace. The marking on the LCD is JG10309-01. Add the "elgin,jg10309-01" compatible string. Signed-off-by: Fabio Estevam <festevam@gmail.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Link: https://patch.msgid.link/20240828180057.3167190-2-festevam@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: tda7419: fix module autoloadingLiao Chen
[ Upstream commit 934b44589da9aa300201a00fe139c5c54f421563 ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Liao Chen <liaochen4@huawei.com> Link: https://patch.msgid.link/20240826084924.368387-4-liaochen4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: intel: fix module autoloadingLiao Chen
[ Upstream commit ae61a3391088d29aa8605c9f2db84295ab993a49 ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by: Liao Chen <liaochen4@huawei.com> Link: https://patch.msgid.link/20240826084924.368387-2-liaochen4@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: Intel: soc-acpi-cht: Make Lenovo Yoga Tab 3 X90F DMI match less strictHans de Goede
[ Upstream commit 839a4ec06f75cec8fec2cc5fc14e921d0c3f7369 ] There are 2G and 4G RAM versions of the Lenovo Yoga Tab 3 X90F and it turns out that the 2G version has a DMI product name of "CHERRYVIEW D1 PLATFORM" where as the 4G version has "CHERRYVIEW C0 PLATFORM". The sys-vendor + product-version check are unique enough that the product-name check is not necessary. Drop the product-name check so that the existing DMI match for the 4G RAM version also matches the 2G RAM version. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Link: https://patch.msgid.link/20240823074305.16873-1-hdegoede@redhat.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30can: mcp251xfd: mcp251xfd_ring_init(): check TX-coalescing configurationMarc Kleine-Budde
[ Upstream commit ac2b81eb8b2d104033560daea886ee84531e3d0a ] When changing the interface from CAN-CC to CAN-FD mode the old coalescing parameters are re-used. This might cause problem, as the configured parameters are too big for CAN-FD mode. During testing an invalid TX coalescing configuration has been seen. The problem should be been fixed in the previous patch, but add a safeguard here to ensure that the number of TEF coalescing buffers (if configured) is exactly the half of all TEF buffers. Link: https://lore.kernel.org/all/20240805-mcp251xfd-fix-ringconfig-v1-2-72086f0ca5ee@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: iwlwifi: clear trans->state earlier upon errorEmmanuel Grumbach
[ Upstream commit 094513f8a2fbddee51b055d8035f995551f98fce ] When the firmware crashes, we first told the op_mode and only then, changed the transport's state. This is a problem if the op_mode's nic_error() handler needs to send a host command: it'll see that the transport's state still reflects that the firmware is alive. Today, this has no consequences since we set the STATUS_FW_ERROR bit and that will prevent sending host commands. iwl_fw_dbg_stop_restart_recording looks at this bit to know not to send a host command for example. To fix the hibernation, we needed to reset the firmware without having an error and checking STATUS_FW_ERROR to see whether the firmware is alive will no longer hold, so this change is necessary as well. Change the flow a bit. Change trans->state before calling the op_mode's nic_error() method and check trans->state instead of STATUS_FW_ERROR. This will keep the current behavior of iwl_fw_dbg_stop_restart_recording upon firmware error, and it'll allow us to call iwl_fw_dbg_stop_restart_recording safely even if STATUS_FW_ERROR is clear, but yet, the firmware is not alive. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.9d7427fbdfd7.Ia056ca57029a382c921d6f7b6a6b28fc480f2f22@changeid [I missed this was a dependency for the hibernation fix, changed the commit message a bit accordingly] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: mac80211: free skb on error path in ieee80211_beacon_get_ap()Dmitry Antipov
[ Upstream commit 786c5be9ac29a39b6f37f1fdd2ea59d0fe35d525 ] In 'ieee80211_beacon_get_ap()', free allocated skb in case of error returned by 'ieee80211_beacon_protect()'. Compile tested only. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://patch.msgid.link/20240805142035.227847-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: iwlwifi: mvm: don't wait for tx queues if firmware is deadEmmanuel Grumbach
[ Upstream commit 3a84454f5204718ca5b4ad2c1f0bf2031e2403d1 ] There is a WARNING in iwl_trans_wait_tx_queues_empty() (that was recently converted from just a message), that can be hit if we wait for TX queues to become empty after firmware died. Clearly, we can't expect anything from the firmware after it's declared dead. Don't call iwl_trans_wait_tx_queues_empty() in this case. While it could be a good idea to stop the flow earlier, the flush functions do some maintenance work that is not related to the firmware, so keep that part of the code running even when the firmware is not running. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.a7cbd794cee9.I44a739fbd4ffcc46b83844dd1c7b2eb0c7b270f6@changeid [edit commit message] Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: iwlwifi: mvm: pause TCM when the firmware is stoppedEmmanuel Grumbach
[ Upstream commit 0668ebc8c2282ca1e7eb96092a347baefffb5fe7 ] Not doing so will make us send a host command to the transport while the firmware is not alive, which will trigger a WARNING. bad state = 0 WARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] RIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi] Call Trace: <TASK> iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm] iwl_mvm_config_scan+0x198/0x260 [iwlmvm] iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm] iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm] process_one_work+0x29e/0x640 worker_thread+0x2df/0x690 ? rescuer_thread+0x540/0x540 kthread+0x192/0x1e0 ? set_kthread_struct+0x90/0x90 ret_from_fork+0x22/0x30 Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.5abe71ca1b6b.I97a968cb8be1f24f94652d9b110ecbf6af73f89e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: iwlwifi: mvm: fix iwl_mvm_scan_fits() calculationDaniel Gabay
[ Upstream commit d44162280899c3fc2c6700e21e491e71c3c96e3d ] The calculation should consider also the 6GHz IE's len, fix that. In addition, in iwl_mvm_sched_scan_start() the scan_fits helper is called only in case non_psc_incldued is true, but it should be called regardless, fix that as well. Signed-off-by: Daniel Gabay <daniel.gabay@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.7db825442fd2.I99f4d6587709de02072fd57957ec7472331c6b1d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30wifi: iwlwifi: lower message level for FW buffer destinationBenjamin Berg
[ Upstream commit f8a129c1e10256c785164ed5efa5d17d45fbd81b ] An invalid buffer destination is not a problem for the driver and it does not make sense to report it with the KERN_ERR message level. As such, change the message to use IWL_DEBUG_FW. Reported-by: Len Brown <lenb@kernel.org> Closes: https://lore.kernel.org/r/CAJvTdKkcxJss=DM2sxgv_MR5BeZ4_OC-3ad6tA40TYH2yqHCWw@mail.gmail.com Signed-off-by: Benjamin Berg <benjamin.berg@intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com> Link: https://patch.msgid.link/20240825191257.20abf78f05bc.Ifbcecc2ae9fb40b9698302507dcba8b922c8d856@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30LoongArch: Define ARCH_IRQ_INIT_FLAGS as IRQ_NOPROBEHuacai Chen
[ Upstream commit 274ea3563e5ab9f468c15bfb9d2492803a66d9be ] Currently we call irq_set_noprobe() in a loop for all IRQs, but indeed it only works for IRQs below NR_IRQS_LEGACY because at init_IRQ() only legacy interrupts have been allocated. Instead, we can define ARCH_IRQ_INIT_FLAGS as IRQ_NOPROBE in asm/hwirq.h and the core will automatically set the flag for all interrupts. Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30net: ftgmac100: Ensure tx descriptor updates are visibleJacky Chou
[ Upstream commit 4186c8d9e6af57bab0687b299df10ebd47534a0a ] The driver must ensure TX descriptor updates are visible before updating TX pointer and TX clear pointer. This resolves TX hangs observed on AST2600 when running iperf3. Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30microblaze: don't treat zero reserved memory regions as errorMike Rapoport
[ Upstream commit 0075df288dd8a7abfe03b3766176c393063591dd ] Before commit 721f4a6526da ("mm/memblock: remove empty dummy entry") the check for non-zero of memblock.reserved.cnt in mmu_init() would always be true either because memblock.reserved.cnt is initialized to 1 or because there were memory reservations earlier. The removal of dummy empty entry in memblock caused this check to fail because now memblock.reserved.cnt is initialized to 0. Remove the check for non-zero of memblock.reserved.cnt because it's perfectly fine to have an empty memblock.reserved array that early in boot. Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Mike Rapoport <rppt@kernel.org> Reviewed-by: Wei Yang <richard.weiyang@gmail.com> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20240729053327.4091459-1-rppt@kernel.org Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30hwmon: (asus-ec-sensors) remove VRM temp X570-E GAMINGRoss Brown
[ Upstream commit 9efaebc0072b8e95505544bf385c20ee8a29d799 ] X570-E GAMING does not have VRM temperature sensor. Signed-off-by: Ross Brown <true.robot.ross@gmail.com> Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20240730062320.5188-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30pinctrl: at91: make it work with current gpiolibThomas Blocher
[ Upstream commit 752f387faaae0ae2e84d3f496922524785e77d60 ] pinctrl-at91 currently does not support the gpio-groups devicetree property and has no pin-range. Because of this at91 gpios stopped working since patch commit 2ab73c6d8323fa1e ("gpio: Support GPIO controllers without pin-ranges") This was discussed in the patches commit fc328a7d1fcce263 ("gpio: Revert regression in sysfs-gpio (gpiolib.c)") commit 56e337f2cf132632 ("Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)"") As a workaround manually set pin-range via gpiochip_add_pin_range() until a) pinctrl-at91 is reworked to support devicetree gpio-groups b) another solution as mentioned in commit 56e337f2cf132632 ("Revert "gpio: Revert regression in sysfs-gpio (gpiolib.c)"") is found Signed-off-by: Thomas Blocher <thomas.blocher@ek-dev.de> Link: https://lore.kernel.org/5b992862-355d-f0de-cd3d-ff99e67a4ff1@ek-dev.de Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30scsi: lpfc: Fix overflow build issueSherry Yang
[ Upstream commit 3417c9574e368f0330637505f00d3814ca8854d2 ] Build failed while enabling "CONFIG_GCOV_KERNEL=y" and "CONFIG_GCOV_PROFILE_ALL=y" with following error: BUILDSTDERR: drivers/scsi/lpfc/lpfc_bsg.c: In function 'lpfc_get_cgnbuf_info': BUILDSTDERR: ./include/linux/fortify-string.h:114:33: error: '__builtin_memcpy' accessing 18446744073709551615 bytes at offsets 0 and 0 overlaps 9223372036854775807 bytes at offset -9223372036854775808 [-Werror=restrict] BUILDSTDERR: 114 | #define __underlying_memcpy __builtin_memcpy BUILDSTDERR: | ^ BUILDSTDERR: ./include/linux/fortify-string.h:637:9: note: in expansion of macro '__underlying_memcpy' BUILDSTDERR: 637 | __underlying_##op(p, q, __fortify_size); \ BUILDSTDERR: | ^~~~~~~~~~~~~ BUILDSTDERR: ./include/linux/fortify-string.h:682:26: note: in expansion of macro '__fortify_memcpy_chk' BUILDSTDERR: 682 | #define memcpy(p, q, s) __fortify_memcpy_chk(p, q, s, \ BUILDSTDERR: | ^~~~~~~~~~~~~~~~~~~~ BUILDSTDERR: drivers/scsi/lpfc/lpfc_bsg.c:5468:9: note: in expansion of macro 'memcpy' BUILDSTDERR: 5468 | memcpy(cgn_buff, cp, cinfosz); BUILDSTDERR: | ^~~~~~ This happens from the commit 06bb7fc0feee ("kbuild: turn on -Wrestrict by default"). Address this issue by using size_t type. Signed-off-by: Sherry Yang <sherry.yang@oracle.com> Link: https://lore.kernel.org/r/20240821065131.1180791-1-sherry.yang@oracle.com Reviewed-by: Justin Tee <justin.tee@broadcom.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ALSA: hda/realtek - FIxed ALC285 headphone no soundKailang Yang
[ Upstream commit 1fa7b099d60ad64f559bd3b8e3f0d94b2e015514 ] Dell platform with ALC215 ALC285 ALC289 ALC225 ALC295 ALC299, plug headphone or headset. It had a chance to get no sound from headphone. Replace depop procedure will solve this issue. Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/d0de1b03fd174520945dde216d765223@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ALSA: hda/realtek - Fixed ALC256 headphone no soundKailang Yang
[ Upstream commit 9b82ff1362f50914c8292902e07be98a9f59d33d ] Dell platform, plug headphone or headset, it had a chance to get no sound from headphone. Replace depop procedure will solve this issue. Signed-off-by: Kailang Yang <kailang@realtek.com> Link: https://lore.kernel.org/bb8e2de30d294dc287944efa0667685a@realtek.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: allow module autoloading for table board_idsHongbo Li
[ Upstream commit 5f7c98b7519a3a847d9182bd99d57ea250032ca1 ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from platform_device_id table. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20240821061955.2273782-3-lihongbo22@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: allow module autoloading for table db1200_pidsHongbo Li
[ Upstream commit 0e9fdab1e8df490354562187cdbb8dec643eae2c ] Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from platform_device_id table. Signed-off-by: Hongbo Li <lihongbo22@huawei.com> Link: https://patch.msgid.link/20240821061955.2273782-2-lihongbo22@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-30ASoC: SOF: mediatek: Add missing board compatibleAlbert Jakieła
[ Upstream commit c0196faaa927321a63e680427e075734ee656e42 ] Add Google Dojo compatible. Signed-off-by: Albert Jakieła <jakiela@google.com> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> Link: https://patch.msgid.link/20240809135627.544429-1-jakiela@google.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18Linux 6.1.111v6.1.111Greg Kroah-Hartman
Link: https://lore.kernel.org/r/20240916114221.021192667@linuxfoundation.org Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Yann Sionneau<ysionneau@kalrayinc.com> Tested-by: Mark Brown <broonie@kernel.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Pavel Machek (CIP) <pavel@denx.de> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Salvatore Bonaccorso <carnil@debian.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18ASoC: meson: axg-card: fix 'use-after-free'Arseniy Krasnov
commit 4f9a71435953f941969a4f017e2357db62d85a86 upstream. Buffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()', so move 'pad' pointer initialization after this function when memory is already reallocated. Kasan bug report: ================================================================== BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc Read of size 8 at addr ffff000000e8b260 by task modprobe/356 CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1 Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194 Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Cc: Stable@vger.kernel.org Signed-off-by: Arseniy Krasnov <avkrasnov@salutedevices.com> Reviewed-by: Jerome Brunet <jbrunet@baylibre.com> Link: https://patch.msgid.link/20240911142425.598631-1-avkrasnov@salutedevices.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18pinctrl: meteorlake: Add Arrow Lake-H/U ACPI IDMika Westerberg
commit a366e46da10d7bfa1a52c3bd31f342a3d0e8e7fe upstream. Intel Arrow Lake-H/U has the same GPIO hardware than Meteor Lake-P but the ACPI ID is different. Add this new ACPI ID to the list of supported devices. Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18drm/i915/guc: prevent a possible int overflow in wq offsetsNikita Zhandarovich
[ Upstream commit d3d37f74683e2f16f2635ee265884f7ca69350ae ] It may be possible for the sum of the values derived from i915_ggtt_offset() and __get_parent_scratch_offset()/ i915_ggtt_offset() to go over the u32 limit before being assigned to wq offsets of u64 type. Mitigate these issues by expanding one of the right operands to u64 to avoid any overflow issues just in case. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: c2aa552ff09d ("drm/i915/guc: Add multi-lrc context registration") Cc: Matthew Brost <matthew.brost@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Link: https://patchwork.freedesktop.org/patch/msgid/20240725155925.14707-1-n.zhandarovich@fintech.ru Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit 1f1c1bd56620b80ae407c5790743e17caad69cec) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18spi: geni-qcom: Fix incorrect free_irq() sequenceJinjie Ruan
[ Upstream commit b787a33864121a565aeb0e88561bf6062a19f99c ] In spi_geni_remove(), the free_irq() sequence is different from that on the probe error path. And the IRQ will still remain and it's interrupt handler may use the dma channel after release dma channel and before free irq, which is not secure, fix it. Fixes: b59c122484ec ("spi: spi-geni-qcom: Add support for GPI dma") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20240909073141.951494-3-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18spi: geni-qcom: Undo runtime PM changes at driver exit timeJinjie Ruan
[ Upstream commit 89e362c883c65ff94b76b9862285f63545fb5274 ] It's important to undo pm_runtime_use_autosuspend() with pm_runtime_dont_use_autosuspend() at driver exit time unless driver initially enabled pm_runtime with devm_pm_runtime_enable() (which handles it for you). Hence, switch to devm_pm_runtime_enable() to fix it, so the pm_runtime_disable() in probe error path and remove function can be removed. Fixes: cfdab2cd85ec ("spi: spi-geni-qcom: Set an autosuspend delay of 250 ms") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20240909073141.951494-2-ruanjinjie@huawei.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18spi: geni-qcom: Convert to platform remove callback returning voidUwe Kleine-König
[ Upstream commit d0b52f6539e008a0d42bf673486bd21b7d2dc191 ] The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is (mostly) ignored and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new() which already returns void. Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20230303172041.2103336-30-u.kleine-koenig@pengutronix.de Signed-off-by: Mark Brown <broonie@kernel.org> Stable-dep-of: 89e362c883c6 ("spi: geni-qcom: Undo runtime PM changes at driver exit time") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18drm/amdgpu/atomfirmware: Silence UBSAN warningAlex Deucher
commit 17ea4383649fdeaff3181ddcf1ff03350d42e591 upstream. Per the comments, these are variable sized arrays. Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/3613 Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 81f7804ba84ee617ed594de934ed87bcc4f83531) Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18dma-buf: heaps: Fix off-by-one in CMA heap fault handlerT.J. Mercier
commit ea5ff5d351b520524019f7ff7f9ce418de2dad87 upstream. Until VM_DONTEXPAND was added in commit 1c1914d6e8c6 ("dma-buf: heaps: Don't track CMA dma-buf pages under RssFile") it was possible to obtain a mapping larger than the buffer size via mremap and bypass the overflow check in dma_buf_mmap_internal. When using such a mapping to attempt to fault past the end of the buffer, the CMA heap fault handler also checks the fault offset against the buffer size, but gets the boundary wrong by 1. Fix the boundary check so that we don't read off the end of the pages array and insert an arbitrary page in the mapping. Reported-by: Xingyu Jin <xingyuj@google.com> Fixes: a5d2d29e24be ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Cc: stable@vger.kernel.org # Applicable >= 5.10. Needs adjustments only for 5.10. Signed-off-by: T.J. Mercier <tjmercier@google.com> Acked-by: John Stultz <jstultz@google.com> Signed-off-by: Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240830192627.2546033-1-tjmercier@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18soundwire: stream: Revert "soundwire: stream: fix programming slave ports ↵Krzysztof Kozlowski
for non-continous port maps" commit 233a95fd574fde1c375c486540a90304a2d2d49f upstream. This reverts commit ab8d66d132bc8f1992d3eb6cab8d32dda6733c84 because it breaks codecs using non-continuous masks in source and sink ports. The commit missed the point that port numbers are not used as indices for iterating over prop.sink_ports or prop.source_ports. Soundwire core and existing codecs expect that the array passed as prop.sink_ports and prop.source_ports is continuous. The port mask still might be non-continuous, but that's unrelated. Reported-by: Bard Liao <yung-chuan.liao@linux.intel.com> Closes: https://lore.kernel.org/all/b6c75eee-761d-44c8-8413-2a5b34ee2f98@linux.intel.com/ Fixes: ab8d66d132bc ("soundwire: stream: fix programming slave ports for non-continous port maps") Acked-by: Bard Liao <yung-chuan.liao@linux.intel.com> Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com> Cc: stable@vger.kernel.org Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Tested-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://lore.kernel.org/r/20240909164746.136629-1-krzysztof.kozlowski@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18spi: nxp-fspi: fix the KASAN report out-of-bounds bugHan Xu
commit 2a8787c1cdc7be24fdd8953ecd1a8743a1006235 upstream. Change the memcpy length to fix the out-of-bounds issue when writing the data that is not 4 byte aligned to TX FIFO. To reproduce the issue, write 3 bytes data to NOR chip. dd if=3b of=/dev/mtd0 [ 36.926103] ================================================================== [ 36.933409] BUG: KASAN: slab-out-of-bounds in nxp_fspi_exec_op+0x26ec/0x2838 [ 36.940514] Read of size 4 at addr ffff00081037c2a0 by task dd/455 [ 36.946721] [ 36.948235] CPU: 3 UID: 0 PID: 455 Comm: dd Not tainted 6.11.0-rc5-gc7b0e37c8434 #1070 [ 36.956185] Hardware name: Freescale i.MX8QM MEK (DT) [ 36.961260] Call trace: [ 36.963723] dump_backtrace+0x90/0xe8 [ 36.967414] show_stack+0x18/0x24 [ 36.970749] dump_stack_lvl+0x78/0x90 [ 36.974451] print_report+0x114/0x5cc [ 36.978151] kasan_report+0xa4/0xf0 [ 36.981670] __asan_report_load_n_noabort+0x1c/0x28 [ 36.986587] nxp_fspi_exec_op+0x26ec/0x2838 [ 36.990800] spi_mem_exec_op+0x8ec/0xd30 [ 36.994762] spi_mem_no_dirmap_read+0x190/0x1e0 [ 36.999323] spi_mem_dirmap_write+0x238/0x32c [ 37.003710] spi_nor_write_data+0x220/0x374 [ 37.007932] spi_nor_write+0x110/0x2e8 [ 37.011711] mtd_write_oob_std+0x154/0x1f0 [ 37.015838] mtd_write_oob+0x104/0x1d0 [ 37.019617] mtd_write+0xb8/0x12c [ 37.022953] mtdchar_write+0x224/0x47c [ 37.026732] vfs_write+0x1e4/0x8c8 [ 37.030163] ksys_write+0xec/0x1d0 [ 37.033586] __arm64_sys_write+0x6c/0x9c [ 37.037539] invoke_syscall+0x6c/0x258 [ 37.041327] el0_svc_common.constprop.0+0x160/0x22c [ 37.046244] do_el0_svc+0x44/0x5c [ 37.049589] el0_svc+0x38/0x78 [ 37.052681] el0t_64_sync_handler+0x13c/0x158 [ 37.057077] el0t_64_sync+0x190/0x194 [ 37.060775] [ 37.062274] Allocated by task 455: [ 37.065701] kasan_save_stack+0x2c/0x54 [ 37.069570] kasan_save_track+0x20/0x3c [ 37.073438] kasan_save_alloc_info+0x40/0x54 [ 37.077736] __kasan_kmalloc+0xa0/0xb8 [ 37.081515] __kmalloc_noprof+0x158/0x2f8 [ 37.085563] mtd_kmalloc_up_to+0x120/0x154 [ 37.089690] mtdchar_write+0x130/0x47c [ 37.093469] vfs_write+0x1e4/0x8c8 [ 37.096901] ksys_write+0xec/0x1d0 [ 37.100332] __arm64_sys_write+0x6c/0x9c [ 37.104287] invoke_syscall+0x6c/0x258 [ 37.108064] el0_svc_common.constprop.0+0x160/0x22c [ 37.112972] do_el0_svc+0x44/0x5c [ 37.116319] el0_svc+0x38/0x78 [ 37.119401] el0t_64_sync_handler+0x13c/0x158 [ 37.123788] el0t_64_sync+0x190/0x194 [ 37.127474] [ 37.128977] The buggy address belongs to the object at ffff00081037c2a0 [ 37.128977] which belongs to the cache kmalloc-8 of size 8 [ 37.141177] The buggy address is located 0 bytes inside of [ 37.141177] allocated 3-byte region [ffff00081037c2a0, ffff00081037c2a3) [ 37.153465] [ 37.154971] The buggy address belongs to the physical page: [ 37.160559] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x89037c [ 37.168596] flags: 0xbfffe0000000000(node=0|zone=2|lastcpupid=0x1ffff) [ 37.175149] page_type: 0xfdffffff(slab) [ 37.179021] raw: 0bfffe0000000000 ffff000800002500 dead000000000122 0000000000000000 [ 37.186788] raw: 0000000000000000 0000000080800080 00000001fdffffff 0000000000000000 [ 37.194553] page dumped because: kasan: bad access detected [ 37.200144] [ 37.201647] Memory state around the buggy address: [ 37.206460] ffff00081037c180: fa fc fc fc fa fc fc fc fa fc fc fc fa fc fc fc [ 37.213701] ffff00081037c200: fa fc fc fc 05 fc fc fc 03 fc fc fc 02 fc fc fc [ 37.220946] >ffff00081037c280: 06 fc fc fc 03 fc fc fc fc fc fc fc fc fc fc fc [ 37.228186] ^ [ 37.232473] ffff00081037c300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.239718] ffff00081037c380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 37.246962] ================================================================== [ 37.254394] Disabling lock debugging due to kernel taint 0+1 records in 0+1 records out 3 bytes copied, 0.335911 s, 0.0 kB/s Fixes: a5356aef6a90 ("spi: spi-mem: Add driver for NXP FlexSPI controller") Cc: stable@kernel.org Signed-off-by: Han Xu <han.xu@nxp.com> Link: https://patch.msgid.link/20240911211146.3337068-1-han.xu@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-09-18net: dpaa: Pad packets to ETH_ZLENSean Anderson
[ Upstream commit cbd7ec083413c6a2e0c326d49e24ec7d12c7a9e0 ] When sending packets under 60 bytes, up to three bytes of the buffer following the data may be leaked. Avoid this by extending all packets to ETH_ZLEN, ensuring nothing is leaked in the padding. This bug can be reproduced by running $ ping -s 11 destination Fixes: 9ad1a3749333 ("dpaa_eth: add support for DPAA Ethernet") Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20240910143144.1439910-1-sean.anderson@linux.dev Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18netfilter: nft_socket: fix sk refcount leaksFlorian Westphal
[ Upstream commit 8b26ff7af8c32cb4148b3e147c52f9e4c695209c ] We must put 'sk' reference before returning. Fixes: 039b1f4f24ec ("netfilter: nft_socket: fix erroneous socket assignment") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net: ftgmac100: Enable TX interrupt to avoid TX timeoutJacky Chou
[ Upstream commit fef2843bb49f414d1523ca007d088071dee0e055 ] Currently, the driver only enables RX interrupt to handle RX packets and TX resources. Sometimes there is not RX traffic, so the TX resource needs to wait for RX interrupt to free. This situation will toggle the TX timeout watchdog when the MAC TX ring has no more resources to transmit packets. Therefore, enable TX interrupt to release TX resources at any time. When I am verifying iperf3 over UDP, the network hangs. Like the log below. root# iperf3 -c 192.168.100.100 -i1 -t10 -u -b0 Connecting to host 192.168.100.100, port 5201 [ 4] local 192.168.100.101 port 35773 connected to 192.168.100.100 port 5201 [ ID] Interval Transfer Bandwidth Total Datagrams [ 4] 0.00-20.42 sec 160 KBytes 64.2 Kbits/sec 20 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 [ 4] 20.42-20.42 sec 0.00 Bytes 0.00 bits/sec 0 - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams [ 4] 0.00-20.42 sec 160 KBytes 64.2 Kbits/sec 0.000 ms 0/20 (0%) [ 4] Sent 20 datagrams iperf3: error - the server has terminated The network topology is FTGMAC connects directly to a PC. UDP does not need to wait for ACK, unlike TCP. Therefore, FTGMAC needs to enable TX interrupt to release TX resources instead of waiting for the RX interrupt. Fixes: 10cbd6407609 ("ftgmac100: Rework NAPI & interrupts handling") Signed-off-by: Jacky Chou <jacky_chou@aspeedtech.com> Link: https://patch.msgid.link/20240906062831.2243399-1-jacky_chou@aspeedtech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18octeontx2-af: Modify SMQ flush sequence to drop packetsNaveen Mamindlapalli
[ Upstream commit 019aba04f08c2102b35ce7fee9d4628d349f56c0 ] The current implementation of SMQ flush sequence waits for the packets in the TM pipeline to be transmitted out of the link. This sequence doesn't succeed in HW when there is any issue with link such as lack of link credits, link down or any other traffic that is fully occupying the link bandwidth (QoS). This patch modifies the SMQ flush sequence to drop the packets after TL1 level (SQM) instead of polling for the packets to be sent out of RPM/CGX link. Fixes: 5d9b976d4480 ("octeontx2-af: Support fixed transmit scheduler topology") Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Reviewed-by: Sunil Kovvuri Goutham <sgoutham@marvell.com> Link: https://patch.msgid.link/20240906045838.1620308-1-naveenm@marvell.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18octeontx2-af: Set XOFF on other child transmit schedulers during SMQ flushNaveen Mamindlapalli
[ Upstream commit e18aab0470d8f6259be82282ffb3fdcfeaeff6c3 ] When multiple transmit scheduler queues feed a TL1 transmit link, the SMQ flush initiated on a low priority queue might get stuck when a high priority queue fully subscribes the transmit link. This inturn effects interface teardown. To avoid this, temporarily XOFF all TL1's other immediate child transmit scheduler queues and also clear any rate limit configuration on all the scheduler queues in SMQ(flush) hierarchy. Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com> Signed-off-by: Sunil Goutham <sgoutham@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net> Stable-dep-of: 019aba04f08c ("octeontx2-af: Modify SMQ flush sequence to drop packets") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18fou: fix initialization of grcMuhammad Usama Anjum
[ Upstream commit 4c8002277167125078e6b9b90137bdf443ebaa08 ] The grc must be initialize first. There can be a condition where if fou is NULL, goto out will be executed and grc would be used uninitialized. Fixes: 7e4196935069 ("fou: Fix null-ptr-deref in GRO.") Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com> Link: https://patch.msgid.link/20240906102839.202798-1-usama.anjum@collabora.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Fix bridge mode operations when there are no VFsBenjamin Poirier
[ Upstream commit b1d305abef4640af1b4f1b4774d513cd81b10cfc ] Currently, trying to set the bridge mode attribute when numvfs=0 leads to a crash: bridge link set dev eth2 hwmode vepa [ 168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030 [...] [ 168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core] [...] [ 168.976037] Call Trace: [ 168.976188] <TASK> [ 168.978620] _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core] [ 168.979074] mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core] [ 168.979471] rtnl_bridge_setlink+0xe9/0x1f0 [ 168.979714] rtnetlink_rcv_msg+0x159/0x400 [ 168.980451] netlink_rcv_skb+0x54/0x100 [ 168.980675] netlink_unicast+0x241/0x360 [ 168.980918] netlink_sendmsg+0x1f6/0x430 [ 168.981162] ____sys_sendmsg+0x3bb/0x3f0 [ 168.982155] ___sys_sendmsg+0x88/0xd0 [ 168.985036] __sys_sendmsg+0x59/0xa0 [ 168.985477] do_syscall_64+0x79/0x150 [ 168.987273] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 168.987773] RIP: 0033:0x7f8f7950f917 (esw->fdb_table.legacy.vepa_fdb is null) The bridge mode is only relevant when there are multiple functions per port. Therefore, prevent setting and getting this setting when there are no VFs. Note that after this change, there are no settings to change on the PF interface using `bridge link` when there are no VFs, so the interface no longer appears in the `bridge link` output. Fixes: 4b89251de024 ("net/mlx5: Support ndo bridge_setlink and getlink") Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Verify support for scheduling element and TSAR typeCarolina Jubran
[ Upstream commit 861cd9b9cb62feb244b8d77e68fd6ddedbbf66e9 ] Before creating a scheduling element in a NIC or E-Switch scheduler, ensure that the requested element type is supported. If the element is of type Transmit Scheduling Arbiter (TSAR), also verify that the specific TSAR type is supported. Fixes: 214baf22870c ("net/mlx5e: Support HTB offload") Fixes: 85c5f7c9200e ("net/mlx5: E-switch, Create QoS on demand") Fixes: 0fe132eac38c ("net/mlx5: E-switch, Allow to add vports to rate groups") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Correct TASR typo into TSARCosmin Ratiu
[ Upstream commit e575d3a6dd22123888defb622b1742aa2d45b942 ] TSAR is the correct spelling (Transmit Scheduling ARbiter). Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com> Reviewed-by: Gal Pressman <gal@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://lore.kernel.org/r/20240613210036.1125203-2-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 861cd9b9cb62 ("net/mlx5: Verify support for scheduling element and TSAR type") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Add missing masks and QoS bit masks for scheduling elementsCarolina Jubran
[ Upstream commit 452ef7f86036392005940de54228d42ca0044192 ] Add the missing masks for supported element types and Transmit Scheduling Arbiter (TSAR) types in scheduling elements. Also, add the corresponding bit masks for these types in the QoS capabilities of a NIC scheduler. Fixes: 214baf22870c ("net/mlx5e: Support HTB offload") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Explicitly set scheduling element and TSAR typeCarolina Jubran
[ Upstream commit c88146abe4d0f8cf659b2b8883fdc33936d2e3b8 ] Ensure the scheduling element type and TSAR type are explicitly initialized in the QoS rate group creation. This prevents potential issues due to default values. Fixes: 1ae258f8b343 ("net/mlx5: E-switch, Introduce rate limiting groups API") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5e: Add missing link modes to ptys2ethtool_mapShahar Shitrit
[ Upstream commit 7617d62cba4a8a3ff3ed3fda0171c43f135c142e ] Add MLX5E_1000BASE_T and MLX5E_100BASE_TX to the legacy modes in ptys2legacy_ethtool_table, since they were missing. Fixes: 665bc53969d7 ("net/mlx5e: Use new ethtool get/set link ksettings API") Signed-off-by: Shahar Shitrit <shshitrit@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Reviewed-by: Carolina Jubran <cjubran@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18net/mlx5: Update the list of the PCI supported devicesMaher Sanalla
[ Upstream commit 7472d157cb8014103105433bcc0705af2e6f7184 ] Add the upcoming ConnectX-9 device ID to the table of supported PCI device IDs. Fixes: f908a35b2218 ("net/mlx5: Update the list of the PCI supported devices") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Tariq Toukan <tariqt@nvidia.com> Signed-off-by: Saeed Mahameed <saeedm@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18igb: Always call igb_xdp_ring_update_tail() under Tx lockSriram Yagnaraman
[ Upstream commit 27717f8b17c098c4373ddb8fe89e1a1899c7779d ] Always call igb_xdp_ring_update_tail() under __netif_tx_lock, add a comment and lockdep assert to indicate that. This is needed to share the same TX ring between XDP, XSK and slow paths. Furthermore, the current XDP implementation is racy on tail updates. Fixes: 9cbc948b5a20 ("igb: add XDP support") Signed-off-by: Sriram Yagnaraman <sriram.yagnaraman@est.tech> [Kurt: Add lockdep assert and fixes tag] Signed-off-by: Kurt Kanzenbach <kurt@linutronix.de> Acked-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com> Tested-by: George Kuruvinakunnel <george.kuruvinakunnel@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-09-18ice: fix accounting for filters shared by multiple VSIsJacob Keller
[ Upstream commit e843cf7b34fe2e0c1afc55e1f3057375c9b77a14 ] When adding a switch filter (such as a MAC or VLAN filter), it is expected that the driver will detect the case where the filter already exists, and return -EEXIST. This is used by calling code such as ice_vc_add_mac_addr, and ice_vsi_add_vlan to avoid incrementing the accounting fields such as vsi->num_vlan or vf->num_mac. This logic works correctly for the case where only a single VSI has added a given switch filter. When a second VSI adds the same switch filter, the driver converts the existing filter from an ICE_FWD_TO_VSI filter into an ICE_FWD_TO_VSI_LIST filter. This saves switch resources, by ensuring that multiple VSIs can re-use the same filter. The ice_add_update_vsi_list() function is responsible for doing this conversion. When first converting a filter from the FWD_TO_VSI into FWD_TO_VSI_LIST, it checks if the VSI being added is the same as the existing rule's VSI. In such a case it returns -EEXIST. However, when the switch rule has already been converted to a FWD_TO_VSI_LIST, the logic is different. Adding a new VSI in this case just requires extending the VSI list entry. The logic for checking if the rule already exists in this case returns 0 instead of -EEXIST. This breaks the accounting logic mentioned above, so the counters for how many MAC and VLAN filters exist for a given VF or VSI no longer accurately reflect the actual count. This breaks other code which relies on these counts. In typical usage this primarily affects such filters generally shared by multiple VSIs such as VLAN 0, or broadcast and multicast MAC addresses. Fix this by correctly reporting -EEXIST in the case of adding the same VSI to a switch rule already converted to ICE_FWD_TO_VSI_LIST. Fixes: 9daf8208dd4d ("ice: Add support for switch filter programming") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>