summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-04-18veth: take into account peer device for NETDEV_XDP_ACT_NDO_XMIT xdp_features ↵Lorenzo Bianconi
flag For veth pairs, NETDEV_XDP_ACT_NDO_XMIT is supported by the current device if the peer one is running a XDP program or if it has GRO enabled. Fix the xdp_features flags reporting considering peer device and not current one for NETDEV_XDP_ACT_NDO_XMIT. Fixes: fccca038f300 ("veth: take into account device reconfiguration for xdp_features flag") Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://lore.kernel.org/r/4f1ca6f6f6b42ae125bfdb5c7782217c83968b2e.1681767806.git.lorenzo@kernel.org Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2023-04-18Merge tag 'mmc-v6.3-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc Pull MMC fixes from Ulf Hansson: "MMC host: - sdhci_am654: Fix support for UHS-I SDR12 and SDR25 speed modes MEMSTICK: - Fix memory leak if card device never gets registered" * tag 'mmc-v6.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: memstick: fix memory leak if card device is never registered mmc: sdhci_am654: Set HIGH_SPEED_ENA for SDR12 and SDR25
2023-04-18Merge tag 'arm-fixes-6.3-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Arnd Bergmann: "There are a number of updates for devicetree files for Qualcomm, Rockchips, and NXP i.MX platforms, addressing mistakes in the DT contents: - Wrong GPIO polarity on some boards - Lower SD card interface speed for better stability - Incorrect power supply, clock, pmic, cache properties - Disable broken hbr3 on sc7280-herobrine - Devicetree warning fixes The only other changes are: - A regression fix for the Amlogic performance monitoring unit driver, along with two related DT changes. - imx_v6_v7_defconfig enables PCI support again. - Trivial fixes for tee, optee and psci firmware drivers, addressing compiler warning and error output" * tag 'arm-fixes-6.3-3' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (32 commits) firmware/psci: demote suspend-mode warning to info level arm64: dts: qcom: sc7280: remove hbr3 support on herobrine boards ARM: imx_v6_v7_defconfig: Fix unintentional disablement of PCI arm64: dts: rockchip: correct panel supplies on some rk3326 boards arm64: dts: rockchip: use just "port" in panel on RockPro64 arm64: dts: rockchip: use just "port" in panel on Pinebook Pro ARM: dts: imx6ull-colibri: Remove unnecessary #address-cells/#size-cells ARM: dts: imx7d-remarkable2: Remove unnecessary #address-cells/#size-cells arm64: dts: imx8mp-verdin: correct off-on-delay arm64: dts: imx8mm-verdin: correct off-on-delay arm64: dts: imx8mm-evk: correct pmic clock source arm64: dts: qcom: sc8280xp-pmics: fix pon compatible and registers arm64: dts: rockchip: Remove non-existing pwm-delay-us property arm64: dts: rockchip: Add clk_rtc_32k to Anbernic xx3 Devices tee: Pass a pointer to virt_to_page() perf/amlogic: adjust register offsets arm64: dts: meson-g12-common: resolve conflict between canvas & pmu arm64: dts: meson-g12-common: specify full DMC range arm64: dts: imx8mp: fix address length for LCDIF2 riscv: dts: canaan: drop invalid spi-max-frequency ...
2023-04-18wifi: mac80211: remove ieee80211_tx_status_8023Felix Fietkau
It is unused and should not be used. In order to avoid limitations in 4-address mode, the driver should always use ieee80211_tx_status_ext for 802.3 frames with a valid sta pointer. Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20230417133751.79160-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: bump FW API to 78 for AX devicesGregory Greenman
Start supporting API version 78 for AX devices. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.5a4dcbf5a2c1.I125808566fe892ee0865e392bf1b1872daafe8ad@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: check firmware response sizeJohannes Berg
Check the firmware response size for responses to the memory read/write command in debugfs before using it. Fixes: 2b55f43f8e47 ("iwlwifi: mvm: Add mem debugfs entry") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.0d56fcaf68ee.I70e9571f3ed7263929b04f8fabad23c9b999e4ea@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: add MLO support to SF - use sta pointerJohannes Berg
For MLO support, use the pointer to the peer MLD instead of the default link station id, since the default link is only used for non-MLO cases. Using the default link sta id is meaningless for MLO. Also remove the rcu protected section since we now avoid the lookup based on sta id. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.40cef48c0592.I8dd666d603d6e1854033e5369c70e78d9303d236@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: configure TLC on link activationJohannes Berg
If the AP station already exists on link activation (which means we're during link switch), configure the TLC in FW so we can immediately transmit once the link is activated. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.1a93de9b7c1f.I42022f24bbe3572f5a082da8c99794ae14281875@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: fix iwl_mvm_max_amsdu_size() for MLOJohannes Berg
For MLO, we cannot use vif->bss_conf.chandef.chan->band, since that will lead to a NULL-ptr dereference as bss_conf isn't used. However, in case of real MLO, we also need to take both LMACs into account if they exist, since the station might be active on both LMACs at the same time. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.3588afc85d79.I11592893bbc191b9548518b8bd782de568a9f848@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: remove RS rate init update argumentJohannes Berg
Track instead whether or not the station was authorized, that's clearer than trying to indicate in the code whether or not the full bandwidth should be used via an 'update' argument. While at it, give rs_fw_rate_init() the iwl_mvm_ prefix. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.92bd8d36e311.I1877a109104d5ffeaaad6a623e89f0c44decc38e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: initialize per-link STA ratescale dataJohannes Berg
When allocating a new link station, initialize the ratescaling data for it. To do that, refactor the initialization code out into a new iwl_mvm_rs_add_sta_link() function. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.441b6a8c60fd.I34f1b3555c25aaa22cc34d1112fc3b6393a20b7c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: rs-fw: properly access sband->iftype_dataJohannes Berg
We need to look up the correct version of this struct depending on the interface type, rather than just checking if the pointer is non-NULL. Fix that. Fixes: befebbb30af0 ("iwlwifi: rs: consider LDPC capability in case of HE") Fixes: b009cf71a982 ("iwlwifi: mvm: only enable HE DCM if we also support TX") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.1fd54368a02c.Ie4db5e8ae224d9a4a63b528da5d63e1b957b9cef@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: only clients can be 20MHz-onlyJohannes Berg
Since only clients to an AP can be 20MHz-only STAs, adjust the code to not make the use of EHT capabilities depend on only the bandwidth, but also the type of interface. Fixes: 701404f1091d ("wifi: iwlwifi: rs: add support for parsing max MCS per NSS/BW in 11be") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.a3a4c931e4a3.I693a07f4d88044c889eee04793883a83bc5ee362@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: fix iwl_mvm_sta_rc_update for MLOJohannes Berg
When this is called it might crash due to the use of deflink's phy context, update all links instead. It really shouldn't be called right now though, but it's better to have safer code until we update this to be with a link parameter. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.fd47d0de8319.I87c5e5bcb2fadd70acc32021eed394fc1eea12a4@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: remove per-STA MFP settingJohannes Berg
When we first add the STA before sending an authentication frame this is false. However, in some cases such as FT or certainly in MLO link switch scenarios, it will be true. If it happens to be true, it causes a firmware assert (in LMAC, 0x2528), because the same bit is used by the firmware for tracking this setting as well as for tracking if the management key has been installed, and then we get this assert from the firmware when installing the MFP key as it thinks it has already been installed. Remove the setting for now, until the firmware disentangles the two. We should be able to set it, in fact we should be setting it speculatively before authentication/association, to avoid processing management frames that should have been protected/encrypted before the key is set. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.adbeb0e0bfed.I400d0ee3721dc4f294313be992d277ba4d9c88d9@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENTJohannes Berg
We can allow NL80211_EXT_FEATURE_SCAN_MIN_PREQ_CONTENT since we just use the elements from mac80211. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.88b1a70365fd.If5030437707ab67e2146291c1517a9b0e31d01ab@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: use BSSID when building probe requestsJohannes Berg
A long time, ago in commit 818965d39177 ("cfg80211: Allow a scan request for a specific BSSID"), the stack started passing the BSSID that should be scanned for. Use it in iwlwifi for the intended optimisation, and to also allow the use of this for an implementation sending multi-link probe requests. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.0be90360cad7.If279c28079a1db34280a824cee7c3f6545fd8b9e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: update mac id managementGregory Greenman
The restriction where MAC ID 0 could be used only for the managed/IBSS vif is not required when using the new MLO FW API. Update the driver. Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.e4355615da92.Iba934ccf8589c3c27a25a390dc5e938312889b45@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18wifi: iwlwifi: mvm: adopt the latest firmware APIEmmanuel Grumbach
The firmware no longer wants the beacon template inside the MAC command. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230417113648.92aed4180a06.I277efa343c88081cb3fc890dcbeae3161cdffe16@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-18LoongArch: module: set section addresses to 0x0Huacai Chen
These got*, plt* and .text.ftrace_trampoline sections specified for LoongArch have non-zero addressses. Non-zero section addresses in a relocatable ELF would confuse GDB when it tries to compute the section offsets and it ends up printing wrong symbol addresses. Therefore, set them to zero, which mirrors the change in commit 5d8591bc0fbaeb6ded ("arm64 module: set plt* section addresses to 0x0"). Cc: stable@vger.kernel.org Reviewed-by: Guo Ren <guoren@kernel.org> Signed-off-by: Chong Qiao <qiaochong@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Mark 3 symbol exports as non-GPLHuacai Chen
vm_map_base, empty_zero_page and invalid_pmd_table could be accessed widely by some out-of-tree non-GPL but important file systems or drivers (e.g. OpenZFS). Let's use EXPORT_SYMBOL() instead of EXPORT_SYMBOL_GPL() to export them, so as to avoid build errors. 1, Details about vm_map_base: This is a LoongArch-specific symbol and may be referenced through macros PCI_IOBASE, VMALLOC_START and VMALLOC_END. 2, Details about empty_zero_page: As it stands today, only 3 architectures export empty_zero_page as a GPL symbol: IA64, LoongArch and MIPS. LoongArch gets the GPL export by inheriting from MIPS, and the MIPS export was first introduced in commit 497d2adcbf50b ("[MIPS] Export empty_zero_page for sake of the ext4 module."). The IA64 export was similar: commit a7d57ecf4216e ("[IA64] Export three symbols for module use") did so for kvm. In both IA64 and MIPS, the export of empty_zero_page was done for satisfying some in-kernel component built as module (kvm and ext4 respectively), and given its reasonably low-level nature, GPL is a reasonable choice. But looking at the bigger picture it is evident most other architectures do not regard it as GPL, so in effect the symbol probably should not be treated as such, in favor of consistency. 3, Details about invalid_pmd_table: Keep consistency with invalid_pte_table and make it be possible by some modules. Cc: stable@vger.kernel.org Reviewed-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Enable PG when wakeup from suspendHuacai Chen
Some firmwares don't enable PG when wakeup from suspend, so do it in kernel. This can improve code compatibility for boot kernel. Signed-off-by: Baoqi Zhang <zhangbaoqi@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Fix _CONST64_(x) as unsignedQing Zhang
Addresses should all be of unsigned type to avoid unnecessary conversions. Signed-off-by: Qing Zhang <zhangqing@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Fix build error if CONFIG_SUSPEND is not setHuacai Chen
We can see the following build error on LoongArch if CONFIG_SUSPEND is not set: ld: drivers/acpi/sleep.o: in function 'acpi_pm_prepare': sleep.c:(.text+0x2b8): undefined reference to 'loongarch_wakeup_start' Here is the call trace: acpi_pm_prepare() __acpi_pm_prepare() acpi_sleep_prepare() acpi_get_wakeup_address() loongarch_wakeup_start() Root cause: loongarch_wakeup_start() is defined in arch/loongarch/power/ suspend_asm.S which is only built under CONFIG_SUSPEND. In order to fix the build error, just let acpi_get_wakeup_address() return 0 if CONFIG_ SUSPEND is not set. Fixes: 366bb35a8e48 ("LoongArch: Add suspend (ACPI S3) support") Reviewed-by: WANG Xuerui <git@xen0n.name> Reported-by: Randy Dunlap <rdunlap@infradead.org> Link: https://lore.kernel.org/all/11215033-fa3c-ecb1-2fc0-e9aeba47be9b@infradead.org/ Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Fix probing of the CRC32 featureHuacai Chen
Not all LoongArch processors support CRC32 instructions. This feature is indicated by CPUCFG1.CRC32 (Bit25) but it is wrongly defined in the previous versions of the ISA manual (and so does in loongarch.h). The CRC32 feature is set unconditionally now, so fix it. BTW, expose the CRC32 feature in /proc/cpuinfo. Cc: stable@vger.kernel.org Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18LoongArch: Make WriteCombine configurable for ioremap()Huacai Chen
LoongArch maintains cache coherency in hardware, but when paired with LS7A chipsets the WUC attribute (Weak-ordered UnCached, which is similar to WriteCombine) is out of the scope of cache coherency machanism for PCIe devices (this is a PCIe protocol violation, which may be fixed in newer chipsets). This means WUC can only used for write-only memory regions now, so this option is disabled by default, making WUC silently fallback to SUC for ioremap(). You can enable this option if the kernel is ensured to run on hardware without this bug. Kernel parameter writecombine=on/off can be used to override the Kconfig option. Cc: stable@vger.kernel.org Suggested-by: WANG Xuerui <kernel@xen0n.name> Reviewed-by: WANG Xuerui <kernel@xen0n.name> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
2023-04-18mlxfw: fix null-ptr-deref in mlxfw_mfa2_tlv_next()Nikita Zhandarovich
Function mlxfw_mfa2_tlv_multi_get() returns NULL if 'tlv' in question does not pass checks in mlxfw_mfa2_tlv_payload_get(). This behaviour may lead to NULL pointer dereference in 'multi->total_len'. Fix this issue by testing mlxfw_mfa2_tlv_multi_get()'s return value against NULL. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 410ed13cae39 ("Add the mlxfw module for Mellanox firmware flash process") Co-developed-by: Natalia Petrova <n.petrova@fintech.ru> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20230417120718.52325-1-n.zhandarovich@fintech.ru Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18Merge branch 'add-ethernet-driver-for-starfive-jh7110-soc'Paolo Abeni
Samin Guo says: ==================== Add Ethernet driver for StarFive JH7110 SoC This series adds ethernet support for the StarFive JH7110 RISC-V SoC, which includes a dwmac-5.20 MAC driver (from Synopsys DesignWare). This series has been tested and works fine on VisionFive-2 v1.2A and v1.3B SBC boards. For more information and support, you can visit RVspace wiki[1]. You can simply review or test the patches at the link [2]. This patchset should be applied after the patchset [3] [4]. [1]: https://wiki.rvspace.org/ [2]: https://github.com/saminGuo/linux/tree/vf2-6.3rc4-gmac-net-next [3]: https://patchwork.kernel.org/project/linux-riscv/cover/20230401111934.130844-1-hal.feng@starfivetech.com [4]: https://patchwork.kernel.org/project/linux-riscv/cover/20230315055813.94740-1-william.qiu@starfivetech.com ==================== Link: https://lore.kernel.org/r/20230417100251.11871-1-samin.guo@starfivetech.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18net: stmmac: dwmac-starfive: Add phy interface settingsSamin Guo
dwmac supports multiple modess. When working under rmii and rgmii, you need to set different phy interfaces. According to the dwmac document, when working in rmii, it needs to be set to 0x4, and rgmii needs to be set to 0x1. The phy interface needs to be set in syscon, the format is as follows: starfive,syscon: <&syscon, offset, shift> Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18net: stmmac: Add glue layer for StarFive JH7110 SoCSamin Guo
This adds StarFive dwmac driver support on the StarFive JH7110 SoC. Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Co-developed-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18dt-bindings: net: Add support StarFive dwmacYanhong Wang
Add documentation to describe StarFive dwmac driver(GMAC). Signed-off-by: Yanhong Wang <yanhong.wang@starfivetech.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18dt-bindings: net: snps,dwmac: Add 'ahb' reset/reset-nameSamin Guo
According to: stmmac_platform.c: stmmac_probe_config_dt stmmac_main.c: stmmac_dvr_probe dwmac controller may require one (stmmaceth) or two (stmmaceth+ahb) reset signals, and the maxItems of resets/reset-names is going to be 2. The gmac of Starfive Jh7110 SOC must have two resets. it uses snps,dwmac-5.20 IP. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18net: stmmac: platform: Add snps,dwmac-5.20 IP compatible stringEmil Renner Berthing
Add "snps,dwmac-5.20" compatible string for 5.20 version that can avoid to define some platform data in the glue layer. Tested-by: Tommaso Merciai <tomm.merciai@gmail.com> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18dt-bindings: net: snps,dwmac: Add dwmac-5.20 versionEmil Renner Berthing
Add dwmac-5.20 IP version to snps.dwmac.yaml Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Emil Renner Berthing <kernel@esmil.dk> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18Merge branch 'r8169-use-new-macros-from-netdev_queues-h'Paolo Abeni
Heiner Kallweit says: ==================== r8169: use new macros from netdev_queues.h Add one missing subqueue version of the macros, and use the new macros in r8169 to simplify the code. ==================== Link: https://lore.kernel.org/r/7147a001-3d9c-a48d-d398-a94c666aa65b@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18r8169: use new macro netif_subqueue_completed_wake in the tx cleanup pathHeiner Kallweit
Use new net core macro netif_subqueue_completed_wake to simplify the code of the tx cleanup path. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18r8169: use new macro netif_subqueue_maybe_stop in rtl8169_start_xmitHeiner Kallweit
Use new net core macro netif_subqueue_maybe_stop in the start_xmit path to simplify the code. Whilst at it, set the tx queue start threshold to twice the stop threshold. Before values were the same, resulting in stopping/starting the queue more often than needed. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18net: add macro netif_subqueue_completed_wakeHeiner Kallweit
Add netif_subqueue_completed_wake, complementing the subqueue versions netif_subqueue_try_stop and netif_subqueue_maybe_stop. Reviewed-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18Merge branch 'bnxt_en-bug-fixes'Paolo Abeni
Michael Chan says: ==================== bnxt_en: Bug fixes This small series contains 2 fixes. The first one fixes the PTP initialization logic on older chips to avoid logging a warning. The second one fixes a potenial NULL pointer dereference in the driver's aux bus unload path. ==================== Link: https://lore.kernel.org/r/20230417065819.122055-1-michael.chan@broadcom.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18bnxt_en: Fix a possible NULL pointer dereference in unload pathKalesh AP
In the driver unload path, the driver currently checks the valid BNXT_FLAG_ROCE_CAP flag in bnxt_rdma_aux_device_uninit() before proceeding. This is flawed because the flag may not be set initially during driver load. It may be set later after the NVRAM setting is changed followed by a firmware reset. Relying on the BNXT_FLAG_ROCE_CAP flag may crash in bnxt_rdma_aux_device_uninit() if the aux device was never initialized: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 PGD 8ae6aa067 P4D 0 Oops: 0000 [#1] SMP NOPTI CPU: 39 PID: 42558 Comm: rmmod Kdump: loaded Tainted: G OE --------- - - 4.18.0-348.el8.x86_64 #1 Hardware name: Dell Inc. PowerEdge R750/0WT8Y6, BIOS 1.5.4 12/17/2021 RIP: 0010:device_del+0x1b/0x410 Code: 89 a5 50 03 00 00 4c 89 a5 58 03 00 00 eb 89 0f 1f 44 00 00 41 56 41 55 41 54 4c 8d a7 80 00 00 00 55 53 48 89 fb 48 83 ec 18 <48> 8b 2f 4c 89 e7 65 48 8b 04 25 28 00 00 00 48 89 44 24 10 31 c0 RSP: 0018:ff7f82bf469a7dc8 EFLAGS: 00010292 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000206 RDI: 0000000000000000 RBP: ff31b7cd114b0ac0 R08: 0000000000000000 R09: ffffffff935c3400 R10: ff31b7cd45bc3440 R11: 0000000000000001 R12: 0000000000000080 R13: ffffffffc1069f40 R14: 0000000000000000 R15: 0000000000000000 FS: 00007fc9903ce740(0000) GS:ff31b7d4ffac0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000992fee004 CR4: 0000000000773ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: bnxt_rdma_aux_device_uninit+0x1f/0x30 [bnxt_en] bnxt_remove_one+0x2f/0x1f0 [bnxt_en] pci_device_remove+0x3b/0xc0 device_release_driver_internal+0x103/0x1f0 driver_detach+0x54/0x88 bus_remove_driver+0x77/0xc9 pci_unregister_driver+0x2d/0xb0 bnxt_exit+0x16/0x2c [bnxt_en] __x64_sys_delete_module+0x139/0x280 do_syscall_64+0x5b/0x1a0 entry_SYSCALL_64_after_hwframe+0x65/0xca RIP: 0033:0x7fc98f3af71b Fix this by modifying the check inside bnxt_rdma_aux_device_uninit() to check for bp->aux_priv instead. We also need to make some changes in bnxt_rdma_aux_device_init() to make sure that bp->aux_priv is set only when the aux device is fully initialized. Fixes: d80d88b0dfff ("bnxt_en: Add auxiliary driver support") Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18bnxt_en: Do not initialize PTP on older P3/P4 chipsMichael Chan
The driver does not support PTP on these older chips and it is assuming that firmware on these older chips will not return the PORT_MAC_PTP_QCFG_RESP_FLAGS_HWRM_ACCESS flag in __bnxt_hwrm_ptp_qcfg(), causing the function to abort quietly. But newer firmware now sets this flag and so __bnxt_hwrm_ptp_qcfg() will proceed further. Eventually it will fail in bnxt_ptp_init() -> bnxt_map_ptp_regs() because there is no code to support the older chips. The driver will then complain: "PTP initialization failed.\n" Fix it so that we abort quietly earlier without going through the unnecessary steps and alarming the user with the warning log. Fixes: ae5c42f0b92c ("bnxt_en: Get PTP hardware capability from firmware") Signed-off-by: Michael Chan <michael.chan@broadcom.com> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18netfilter: nf_tables: tighten netlink attribute requirements for catch-all ↵Pablo Neira Ayuso
elements If NFT_SET_ELEM_CATCHALL is set on, then userspace provides no set element key. Otherwise, bail out with -EINVAL. Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2023-04-18cxgb4: fix use after free bugs caused by circular dependency problemDuoming Zhou
The flower_stats_timer can schedule flower_stats_work and flower_stats_work can also arm the flower_stats_timer. The process is shown below: ----------- timer schedules work ------------ ch_flower_stats_cb() //timer handler schedule_work(&adap->flower_stats_work); ----------- work arms timer ------------ ch_flower_stats_handler() //workqueue callback function mod_timer(&adap->flower_stats_timer, ...); When the cxgb4 device is detaching, the timer and workqueue could still be rearmed. The process is shown below: (cleanup routine) | (timer and workqueue routine) remove_one() | free_some_resources() | ch_flower_stats_cb() //timer cxgb4_cleanup_tc_flower() | schedule_work() del_timer_sync() | | ch_flower_stats_handler() //workqueue | mod_timer() cancel_work_sync() | kfree(adapter) //FREE | ch_flower_stats_cb() //timer | adap->flower_stats_work //USE This patch changes del_timer_sync() to timer_shutdown_sync(), which could prevent rearming of the timer from the workqueue. Fixes: e0f911c81e93 ("cxgb4: fetch stats for offloaded tc flower flows") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Link: https://lore.kernel.org/r/20230415081227.7463-1-duoming@zju.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2023-04-18netfilter: nf_tables: validate catch-all set elementsPablo Neira Ayuso
catch-all set element might jump/goto to chain that uses expressions that require validation. Fixes: aaa31047a6d2 ("netfilter: nftables: add catch-all set element support") Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
2023-04-17Merge branch 'ocelot-felix-driver-support-for-preemptible-traffic-classes'Jakub Kicinski
Vladimir Oltean says: ==================== Ocelot/Felix driver support for preemptible traffic classes The series "Add tc-mqprio and tc-taprio support for preemptible traffic classes" from: https://lore.kernel.org/netdev/20230220122343.1156614-1-vladimir.oltean@nxp.com/ was eventually submitted in a form without the support for the Ocelot/Felix switch driver. This patch set picks up that work again, and presents a fairly modified form compared to the original. ==================== Link: https://lore.kernel.org/r/20230415170551.3939607-1-vladimir.oltean@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-17net: mscc: ocelot: add support for preemptible traffic classesVladimir Oltean
In order to not transmit (preemptible) frames which will be received by the link partner as corrupted (because it doesn't support FP), the hardware requires the driver to program the QSYS_PREEMPTION_CFG_P_QUEUES register only after the MAC Merge layer becomes active (verification succeeds, or was disabled). There are some cases when FP is known (through experimentation) to be broken. Give priority to FP over cut-through switching, and disable FP for known broken link modes. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-17net: dsa: felix: act upon the mqprio qopt in taprio offloadVladimir Oltean
The mqprio queue configuration can appear either through TC_SETUP_QDISC_MQPRIO or through TC_SETUP_QDISC_TAPRIO. Make sure both are treated in the same way. Code does nothing new for now (except for rejecting multiple TXQs per TC, which is a useless concept with DSA switches). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ferenc Fejes <fejes@inf.elte.hu> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-17net: mscc: ocelot: add support for mqprio offloadVladimir Oltean
This doesn't apply anything to hardware and in general doesn't do anything that the software variant doesn't do, except for checking that there isn't more than 1 TXQ per TC (TXQs for a DSA switch are a dubious concept anyway). The reason we add this is to be able to parse one more field added to struct tc_mqprio_qopt_offload, namely preemptible_tcs. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Ferenc Fejes <fejes@inf.elte.hu> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-17net: mscc: ocelot: don't rely on cached verify_status in ocelot_port_get_mm()Vladimir Oltean
ocelot_mm_update_port_status() updates mm->verify_status, but when the verification state of a port changes, an IRQ isn't emitted, but rather, only when the verification state reaches one of the final states (like DISABLED, FAILED, SUCCEEDED) - things that would affect mm->tx_active, which is what the IRQ *is* actually emitted for. That is to say, user space may miss reports of an intermediary MAC Merge verification state (like from INITIAL to VERIFYING), unless there was an IRQ notifying the driver of the change in mm->tx_active as well. This is not a huge deal, but for reliable reporting to user space, let's call ocelot_mm_update_port_status() synchronously from ocelot_port_get_mm(), which makes user space see the current MM status. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-04-17net: mscc: ocelot: optimize ocelot_mm_irq()Vladimir Oltean
The MAC Merge IRQ of all ports is shared with the PTP TX timestamp IRQ of all ports, which means that currently, when a PTP TX timestamp is generated, felix_irq_handler() also polls for the MAC Merge layer status of all ports, looking for changes. This makes the kernel do more work, and under certain circumstances may make ptp4l require a tx_timestamp_timeout argument higher than before. Changes to the MAC Merge layer status are only to be expected under certain conditions - its TX direction needs to be enabled - so we can check early if that is the case, and omit register access otherwise. Make ocelot_mm_update_port_status() skip register access if mm->tx_enabled is unset, and also call it once more, outside IRQ context, from ocelot_port_set_mm(), when mm->tx_enabled transitions from true to false, because an IRQ is also expected in that case. Also, a port may have its MAC Merge layer enabled but it may not have generated the interrupt. In that case, there's no point in writing to DEV_MM_STATUS to acknowledge that IRQ. We can reduce the number of register writes per port with MM enabled by keeping an "ack" variable which writes the "write-one-to-clear" bits. Those are 3 in number: PRMPT_ACTIVE_STICKY, UNEXP_RX_PFRM_STICKY and UNEXP_TX_PFRM_STICKY. The other fields in DEV_MM_STATUS are read-only and it doesn't matter what is written to them, so writing zero is just fine. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
generated by cgit (git 2.34.1) at 2025-09-12 16:55:58 +0000