From: Greg Kroah-Hartman Date: Thu, 4 Mar 2021 13:53:51 +0000 (+0100) Subject: 5.11-stable patches X-Git-Tag: v4.4.260~53 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=80ffc19b0147fb21cdd2cb1b761ffd2ba3703158;p=thirdparty%2Fkernel%2Fstable-queue.git 5.11-stable patches added patches: iwlwifi-add-new-cards-for-so-and-qu-family.patch net-usb-qmi_wwan-support-zte-p685m-modem.patch x86-build-treat-r_386_plt32-relocation-as-r_386_pc32.patch --- diff --git a/queue-5.11/iwlwifi-add-new-cards-for-so-and-qu-family.patch b/queue-5.11/iwlwifi-add-new-cards-for-so-and-qu-family.patch new file mode 100644 index 00000000000..1cee267628b --- /dev/null +++ b/queue-5.11/iwlwifi-add-new-cards-for-so-and-qu-family.patch @@ -0,0 +1,111 @@ +From 410f758529bc227b186ba0846bcc75ac0700ffb2 Mon Sep 17 00:00:00 2001 +From: Ihab Zhaika +Date: Sat, 6 Feb 2021 13:01:10 +0200 +Subject: iwlwifi: add new cards for So and Qu family + +From: Ihab Zhaika + +commit 410f758529bc227b186ba0846bcc75ac0700ffb2 upstream. + +add few PCI ID'S for So with Hr and Qu with Hr in AX family. + +Cc: stable@vger.kernel.org +Signed-off-by: Ihab Zhaika +Signed-off-by: Luca Coelho +Link: https://lore.kernel.org/r/iwlwifi.20210206130110.6f0c1849f7dc.I647b4d22f9468c2f34b777a4bfa445912c6f04f0@changeid +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/intel/iwlwifi/cfg/22000.c | 18 ++++++++++++++++ + drivers/net/wireless/intel/iwlwifi/iwl-config.h | 3 ++ + drivers/net/wireless/intel/iwlwifi/pcie/drv.c | 26 ++++++++++++++++++++++++ + 3 files changed, 47 insertions(+) + +--- a/drivers/net/wireless/intel/iwlwifi/cfg/22000.c ++++ b/drivers/net/wireless/intel/iwlwifi/cfg/22000.c +@@ -635,6 +635,24 @@ const struct iwl_cfg iwl_cfg_snj_a0_mr_a + .num_rbds = IWL_NUM_RBDS_AX210_HE, + }; + ++const struct iwl_cfg iwl_cfg_so_a0_hr_a0 = { ++ .fw_name_pre = IWL_SO_A_HR_B_FW_PRE, ++ IWL_DEVICE_AX210, ++ .num_rbds = IWL_NUM_RBDS_AX210_HE, ++}; ++ ++const struct iwl_cfg iwl_cfg_quz_a0_hr_b0 = { ++ .fw_name_pre = IWL_QUZ_A_HR_B_FW_PRE, ++ IWL_DEVICE_22500, ++ /* ++ * This device doesn't support receiving BlockAck with a large bitmap ++ * so we need to restrict the size of transmitted aggregation to the ++ * HT size; mac80211 would otherwise pick the HE max (256) by default. ++ */ ++ .max_tx_agg_size = IEEE80211_MAX_AMPDU_BUF_HT, ++ .num_rbds = IWL_NUM_RBDS_22000_HE, ++}; ++ + MODULE_FIRMWARE(IWL_QU_B_HR_B_MODULE_FIRMWARE(IWL_22000_UCODE_API_MAX)); + MODULE_FIRMWARE(IWL_QNJ_B_HR_B_MODULE_FIRMWARE(IWL_22000_UCODE_API_MAX)); + MODULE_FIRMWARE(IWL_QU_C_HR_B_MODULE_FIRMWARE(IWL_22000_UCODE_API_MAX)); +--- a/drivers/net/wireless/intel/iwlwifi/iwl-config.h ++++ b/drivers/net/wireless/intel/iwlwifi/iwl-config.h +@@ -418,6 +418,7 @@ struct iwl_cfg { + #define IWL_CFG_MAC_TYPE_QU 0x33 + #define IWL_CFG_MAC_TYPE_QUZ 0x35 + #define IWL_CFG_MAC_TYPE_QNJ 0x36 ++#define IWL_CFG_MAC_TYPE_SO 0x37 + #define IWL_CFG_MAC_TYPE_SNJ 0x42 + #define IWL_CFG_MAC_TYPE_MA 0x44 + +@@ -604,6 +605,8 @@ extern const struct iwl_cfg iwlax201_cfg + extern const struct iwl_cfg iwl_cfg_ma_a0_gf_a0; + extern const struct iwl_cfg iwl_cfg_ma_a0_mr_a0; + extern const struct iwl_cfg iwl_cfg_snj_a0_mr_a0; ++extern const struct iwl_cfg iwl_cfg_so_a0_hr_a0; ++extern const struct iwl_cfg iwl_cfg_quz_a0_hr_b0; + #endif /* CONFIG_IWLMVM */ + + #endif /* __IWL_CONFIG_H__ */ +--- a/drivers/net/wireless/intel/iwlwifi/pcie/drv.c ++++ b/drivers/net/wireless/intel/iwlwifi/pcie/drv.c +@@ -934,6 +934,11 @@ static const struct iwl_dev_info iwl_dev + IWL_CFG_RF_TYPE_HR1, IWL_CFG_ANY, + IWL_CFG_ANY, IWL_CFG_ANY, + iwl_quz_a0_hr1_b0, iwl_ax101_name), ++ _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, ++ IWL_CFG_MAC_TYPE_QUZ, SILICON_B_STEP, ++ IWL_CFG_RF_TYPE_HR2, IWL_CFG_ANY, ++ IWL_CFG_NO_160, IWL_CFG_ANY, ++ iwl_cfg_quz_a0_hr_b0, iwl_ax203_name), + + /* Ma */ + _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, +@@ -952,6 +957,27 @@ static const struct iwl_dev_info iwl_dev + IWL_CFG_ANY, IWL_CFG_ANY, + iwl_cfg_snj_a0_mr_a0, iwl_ma_name), + ++/* So with Hr */ ++ _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, ++ IWL_CFG_MAC_TYPE_SO, IWL_CFG_ANY, ++ IWL_CFG_RF_TYPE_HR2, IWL_CFG_ANY, ++ IWL_CFG_NO_160, IWL_CFG_ANY, ++ iwl_cfg_so_a0_hr_a0, iwl_ax203_name), ++ _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, ++ IWL_CFG_MAC_TYPE_SO, IWL_CFG_ANY, ++ IWL_CFG_RF_TYPE_HR2, IWL_CFG_ANY, ++ IWL_CFG_NO_160, IWL_CFG_ANY, ++ iwl_cfg_so_a0_hr_a0, iwl_ax203_name), ++ _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, ++ IWL_CFG_MAC_TYPE_SO, IWL_CFG_ANY, ++ IWL_CFG_RF_TYPE_HR1, IWL_CFG_ANY, ++ IWL_CFG_160, IWL_CFG_ANY, ++ iwl_cfg_so_a0_hr_a0, iwl_ax101_name), ++ _IWL_DEV_INFO(IWL_CFG_ANY, IWL_CFG_ANY, ++ IWL_CFG_MAC_TYPE_SO, IWL_CFG_ANY, ++ IWL_CFG_RF_TYPE_HR2, IWL_CFG_ANY, ++ IWL_CFG_160, IWL_CFG_ANY, ++ iwl_cfg_so_a0_hr_a0, iwl_ax201_name) + + #endif /* CONFIG_IWLMVM */ + }; diff --git a/queue-5.11/net-usb-qmi_wwan-support-zte-p685m-modem.patch b/queue-5.11/net-usb-qmi_wwan-support-zte-p685m-modem.patch new file mode 100644 index 00000000000..4f7ad54ddad --- /dev/null +++ b/queue-5.11/net-usb-qmi_wwan-support-zte-p685m-modem.patch @@ -0,0 +1,65 @@ +From 88eee9b7b42e69fb622ddb3ff6f37e8e4347f5b2 Mon Sep 17 00:00:00 2001 +From: Lech Perczak +Date: Tue, 23 Feb 2021 19:34:56 +0100 +Subject: net: usb: qmi_wwan: support ZTE P685M modem +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Lech Perczak + +commit 88eee9b7b42e69fb622ddb3ff6f37e8e4347f5b2 upstream. + +Now that interface 3 in "option" driver is no longer mapped, add device +ID matching it to qmi_wwan. + +The modem is used inside ZTE MF283+ router and carriers identify it as +such. +Interface mapping is: +0: QCDM, 1: AT (PCUI), 2: AT (Modem), 3: QMI, 4: ADB + +T: Bus=02 Lev=02 Prnt=02 Port=05 Cnt=01 Dev#= 3 Spd=480 MxCh= 0 +D: Ver= 2.01 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 +P: Vendor=19d2 ProdID=1275 Rev=f0.00 +S: Manufacturer=ZTE,Incorporated +S: Product=ZTE Technologies MSM +S: SerialNumber=P685M510ZTED0000CP&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&0 +C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=500mA +I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=option +E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option +E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms +E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option +E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms +E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan +E: Ad=87(I) Atr=03(Int.) MxPS= 8 Ivl=32ms +E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms +I:* If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none) +E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms +E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms + +Acked-by: Bjørn Mork +Signed-off-by: Lech Perczak +Link: https://lore.kernel.org/r/20210223183456.6377-1-lech.perczak@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/usb/qmi_wwan.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/usb/qmi_wwan.c ++++ b/drivers/net/usb/qmi_wwan.c +@@ -1235,6 +1235,7 @@ static const struct usb_device_id produc + {QMI_FIXED_INTF(0x19d2, 0x1255, 4)}, + {QMI_FIXED_INTF(0x19d2, 0x1256, 4)}, + {QMI_FIXED_INTF(0x19d2, 0x1270, 5)}, /* ZTE MF667 */ ++ {QMI_FIXED_INTF(0x19d2, 0x1275, 3)}, /* ZTE P685M */ + {QMI_FIXED_INTF(0x19d2, 0x1401, 2)}, + {QMI_FIXED_INTF(0x19d2, 0x1402, 2)}, /* ZTE MF60 */ + {QMI_FIXED_INTF(0x19d2, 0x1424, 2)}, diff --git a/queue-5.11/x86-build-treat-r_386_plt32-relocation-as-r_386_pc32.patch b/queue-5.11/x86-build-treat-r_386_plt32-relocation-as-r_386_pc32.patch new file mode 100644 index 00000000000..762099bbd0b --- /dev/null +++ b/queue-5.11/x86-build-treat-r_386_plt32-relocation-as-r_386_pc32.patch @@ -0,0 +1,104 @@ +From bb73d07148c405c293e576b40af37737faf23a6a Mon Sep 17 00:00:00 2001 +From: Fangrui Song +Date: Wed, 27 Jan 2021 12:56:00 -0800 +Subject: x86/build: Treat R_386_PLT32 relocation as R_386_PC32 + +From: Fangrui Song + +commit bb73d07148c405c293e576b40af37737faf23a6a upstream. + +This is similar to commit + + b21ebf2fb4cd ("x86: Treat R_X86_64_PLT32 as R_X86_64_PC32") + +but for i386. As far as the kernel is concerned, R_386_PLT32 can be +treated the same as R_386_PC32. + +R_386_PLT32/R_X86_64_PLT32 are PC-relative relocation types which +can only be used by branches. If the referenced symbol is defined +externally, a PLT will be used. + +R_386_PC32/R_X86_64_PC32 are PC-relative relocation types which can be +used by address taking operations and branches. If the referenced symbol +is defined externally, a copy relocation/canonical PLT entry will be +created in the executable. + +On x86-64, there is no PIC vs non-PIC PLT distinction and an +R_X86_64_PLT32 relocation is produced for both `call/jmp foo` and +`call/jmp foo@PLT` with newer (2018) GNU as/LLVM integrated assembler. +This avoids canonical PLT entries (st_shndx=0, st_value!=0). + +On i386, there are 2 types of PLTs, PIC and non-PIC. Currently, +the GCC/GNU as convention is to use R_386_PC32 for non-PIC PLT and +R_386_PLT32 for PIC PLT. Copy relocations/canonical PLT entries +are possible ABI issues but GCC/GNU as will likely keep the status +quo because (1) the ABI is legacy (2) the change will drop a GNU +ld diagnostic for non-default visibility ifunc in shared objects. + +clang-12 -fno-pic (since [1]) can emit R_386_PLT32 for compiler +generated function declarations, because preventing canonical PLT +entries is weighed over the rare ifunc diagnostic. + +Further info for the more interested: + + https://github.com/ClangBuiltLinux/linux/issues/1210 + https://sourceware.org/bugzilla/show_bug.cgi?id=27169 + https://github.com/llvm/llvm-project/commit/a084c0388e2a59b9556f2de0083333232da3f1d6 [1] + + [ bp: Massage commit message. ] + +Reported-by: Arnd Bergmann +Signed-off-by: Fangrui Song +Signed-off-by: Borislav Petkov +Reviewed-by: Nick Desaulniers +Reviewed-by: Nathan Chancellor +Tested-by: Nick Desaulniers +Tested-by: Nathan Chancellor +Tested-by: Sedat Dilek +Link: https://lkml.kernel.org/r/20210127205600.1227437-1-maskray@google.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/module.c | 1 + + arch/x86/tools/relocs.c | 12 ++++++++---- + 2 files changed, 9 insertions(+), 4 deletions(-) + +--- a/arch/x86/kernel/module.c ++++ b/arch/x86/kernel/module.c +@@ -114,6 +114,7 @@ int apply_relocate(Elf32_Shdr *sechdrs, + *location += sym->st_value; + break; + case R_386_PC32: ++ case R_386_PLT32: + /* Add the value, subtract its position */ + *location += sym->st_value - (uint32_t)location; + break; +--- a/arch/x86/tools/relocs.c ++++ b/arch/x86/tools/relocs.c +@@ -867,9 +867,11 @@ static int do_reloc32(struct section *se + case R_386_PC32: + case R_386_PC16: + case R_386_PC8: ++ case R_386_PLT32: + /* +- * NONE can be ignored and PC relative relocations don't +- * need to be adjusted. ++ * NONE can be ignored and PC relative relocations don't need ++ * to be adjusted. Because sym must be defined, R_386_PLT32 can ++ * be treated the same way as R_386_PC32. + */ + break; + +@@ -910,9 +912,11 @@ static int do_reloc_real(struct section + case R_386_PC32: + case R_386_PC16: + case R_386_PC8: ++ case R_386_PLT32: + /* +- * NONE can be ignored and PC relative relocations don't +- * need to be adjusted. ++ * NONE can be ignored and PC relative relocations don't need ++ * to be adjusted. Because sym must be defined, R_386_PLT32 can ++ * be treated the same way as R_386_PC32. + */ + break; +