From: Greg Kroah-Hartman Date: Wed, 12 May 2021 08:58:28 +0000 (+0200) Subject: 5.12-stable patches X-Git-Tag: v5.4.119~82 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=2766a49f8a05709fc0044085e2d14e023069af5f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.12-stable patches added patches: asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch asoc-tlv320aic32x4-register-clocks-before-registering-component.patch async_xor-increase-src_offs-when-dropping-destination-page.patch fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch iio-adc-ad7476-fix-remove-handling.patch iio-hid-sensor-rotation-fix-quaternion-data-not-correct.patch iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch iio-magnetometer-yas530-fix-return-value-on-error-path.patch iio-magnetometer-yas530-include-right-header.patch iio-sx9310-fix-access-to-variable-dt-array.patch iio-sx9310-fix-write_.._debounce.patch kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch mips-pci-mt7620-fix-pll-lock-check.patch mips-pci-rt2880-fix-slot-0-configuration.patch misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch pci-allow-vpd-access-for-qlogic-isp2722.patch pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch pci-xgene-fix-cfg-resource-mapping.patch phy-cadence-sierra-fix-phy-power_on-sequence.patch phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch sc16is7xx-defer-probe-if-device-read-fails.patch selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch usb-serial-xr-fix-csize-handling.patch usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch usb-typec-tcpm-update-power-supply-once-partner-accepts.patch usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch --- diff --git a/queue-5.12/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch b/queue-5.12/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch new file mode 100644 index 00000000000..1e7714c9a22 --- /dev/null +++ b/queue-5.12/asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch @@ -0,0 +1,101 @@ +From a523ef731ac6674dc07574f31bf44cc5bfa14e4d Mon Sep 17 00:00:00 2001 +From: Lukasz Majczak +Date: Thu, 15 Apr 2021 14:43:47 +0200 +Subject: ASoC: Intel: kbl_da7219_max98927: Fix kabylake_ssp_fixup function + +From: Lukasz Majczak + +commit a523ef731ac6674dc07574f31bf44cc5bfa14e4d upstream. + +kabylake_ssp_fixup function uses snd_soc_dpcm to identify the +codecs DAIs. The HW parameters are changed based on the codec DAI of the +stream. The earlier approach to get snd_soc_dpcm was using container_of() +macro on snd_pcm_hw_params. + +The structures have been modified over time and snd_soc_dpcm does not have +snd_pcm_hw_params as a reference but as a copy. This causes the current +driver to crash when used. + +This patch changes the way snd_soc_dpcm is extracted. snd_soc_pcm_runtime +holds 2 dpcm instances (one for playback and one for capture). 2 codecs +on the SSP are dmic (capture) and speakers (playback). Based on the +stream direction, snd_soc_dpcm is extracted from snd_soc_pcm_runtime. + +Tested for all use cases of the driver. +Based on similar fix in kbl_rt5663_rt5514_max98927.c +from Harsha Priya and +Vamshi Krishna Gopal + +Cc: # 5.4+ +Signed-off-by: Lukasz Majczak +Acked-by: Pierre-Louis Bossart +Link: https://lore.kernel.org/r/20210415124347.475432-1-lma@semihalf.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/intel/boards/kbl_da7219_max98927.c | 38 +++++++++++++++++++++------ + 1 file changed, 30 insertions(+), 8 deletions(-) + +--- a/sound/soc/intel/boards/kbl_da7219_max98927.c ++++ b/sound/soc/intel/boards/kbl_da7219_max98927.c +@@ -282,12 +282,34 @@ static int kabylake_ssp_fixup(struct snd + struct snd_interval *chan = hw_param_interval(params, + SNDRV_PCM_HW_PARAM_CHANNELS); + struct snd_mask *fmt = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT); +- struct snd_soc_dpcm *dpcm = container_of( +- params, struct snd_soc_dpcm, hw_params); +- struct snd_soc_dai_link *fe_dai_link = dpcm->fe->dai_link; +- struct snd_soc_dai_link *be_dai_link = dpcm->be->dai_link; ++ struct snd_soc_dpcm *dpcm, *rtd_dpcm = NULL; + + /* ++ * The following loop will be called only for playback stream ++ * In this platform, there is only one playback device on every SSP ++ */ ++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_PLAYBACK, dpcm) { ++ rtd_dpcm = dpcm; ++ break; ++ } ++ ++ /* ++ * This following loop will be called only for capture stream ++ * In this platform, there is only one capture device on every SSP ++ */ ++ for_each_dpcm_fe(rtd, SNDRV_PCM_STREAM_CAPTURE, dpcm) { ++ rtd_dpcm = dpcm; ++ break; ++ } ++ ++ if (!rtd_dpcm) ++ return -EINVAL; ++ ++ /* ++ * The above 2 loops are mutually exclusive based on the stream direction, ++ * thus rtd_dpcm variable will never be overwritten ++ */ ++ /* + * Topology for kblda7219m98373 & kblmax98373 supports only S24_LE, + * where as kblda7219m98927 & kblmax98927 supports S16_LE by default. + * Skipping the port wise FE and BE configuration for kblda7219m98373 & +@@ -309,9 +331,9 @@ static int kabylake_ssp_fixup(struct snd + /* + * The ADSP will convert the FE rate to 48k, stereo, 24 bit + */ +- if (!strcmp(fe_dai_link->name, "Kbl Audio Port") || +- !strcmp(fe_dai_link->name, "Kbl Audio Headset Playback") || +- !strcmp(fe_dai_link->name, "Kbl Audio Capture Port")) { ++ if (!strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Port") || ++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Headset Playback") || ++ !strcmp(rtd_dpcm->fe->dai_link->name, "Kbl Audio Capture Port")) { + rate->min = rate->max = 48000; + chan->min = chan->max = 2; + snd_mask_none(fmt); +@@ -322,7 +344,7 @@ static int kabylake_ssp_fixup(struct snd + * The speaker on the SSP0 supports S16_LE and not S24_LE. + * thus changing the mask here + */ +- if (!strcmp(be_dai_link->name, "SSP0-Codec")) ++ if (!strcmp(rtd_dpcm->be->dai_link->name, "SSP0-Codec")) + snd_mask_set_format(fmt, SNDRV_PCM_FORMAT_S16_LE); + + return 0; diff --git a/queue-5.12/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch b/queue-5.12/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch new file mode 100644 index 00000000000..a581879be8d --- /dev/null +++ b/queue-5.12/asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch @@ -0,0 +1,54 @@ +From d58970da324732686529655c21791cef0ee547c4 Mon Sep 17 00:00:00 2001 +From: Pierre-Louis Bossart +Date: Fri, 12 Mar 2021 12:02:30 -0600 +Subject: ASoC: samsung: tm2_wm5110: check of of_parse return value + +From: Pierre-Louis Bossart + +commit d58970da324732686529655c21791cef0ee547c4 upstream. + +cppcheck warning: + +sound/soc/samsung/tm2_wm5110.c:605:6: style: Variable 'ret' is +reassigned a value before the old one has been +used. [redundantAssignment] + ret = devm_snd_soc_register_component(dev, &tm2_component, + ^ +sound/soc/samsung/tm2_wm5110.c:554:7: note: ret is assigned + ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", + ^ +sound/soc/samsung/tm2_wm5110.c:605:6: note: ret is overwritten + ret = devm_snd_soc_register_component(dev, &tm2_component, + ^ + +The args is a stack variable, so it could have junk (uninitialized) +therefore args.np could have a non-NULL and random value even though +property was missing. Later could trigger invalid pointer dereference. + +There's no need to check for args.np because args.np won't be +initialized on errors. + +Fixes: 8d1513cef51a ("ASoC: samsung: Add support for HDMI audio on TM2 board") +Cc: +Suggested-by: Krzysztof Kozlowski +Reviewed-by: Krzysztof Kozlowski +Reviewed-by: Sylwester Nawrocki +Signed-off-by: Pierre-Louis Bossart +Link: https://lore.kernel.org/r/20210312180231.2741-2-pierre-louis.bossart@linux.intel.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/samsung/tm2_wm5110.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/soc/samsung/tm2_wm5110.c ++++ b/sound/soc/samsung/tm2_wm5110.c +@@ -553,7 +553,7 @@ static int tm2_probe(struct platform_dev + + ret = of_parse_phandle_with_args(dev->of_node, "i2s-controller", + cells_name, i, &args); +- if (!args.np) { ++ if (ret) { + dev_err(dev, "i2s-controller property parse error: %d\n", i); + ret = -EINVAL; + goto dai_node_put; diff --git a/queue-5.12/asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch b/queue-5.12/asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch new file mode 100644 index 00000000000..a3b008aacaa --- /dev/null +++ b/queue-5.12/asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch @@ -0,0 +1,40 @@ +From 29654ed8384e9dbaf4cfba689dbcb664a6ab4bb7 Mon Sep 17 00:00:00 2001 +From: Annaliese McDermond +Date: Wed, 31 Mar 2021 18:21:45 +0000 +Subject: ASoC: tlv320aic32x4: Increase maximum register in regmap + +From: Annaliese McDermond + +commit 29654ed8384e9dbaf4cfba689dbcb664a6ab4bb7 upstream. + +AIC32X4_REFPOWERUP was added as a register, but the maximum register value +in the regmap and regmap range was not correspondingly increased. This +caused an error when this register was attempted to be written. + +Fixes: ec96690de82c ("ASoC: tlv320aic32x4: Enable fast charge") +Cc: stable@vger.kernel.org +Signed-off-by: Annaliese McDermond +Link: https://lore.kernel.org/r/0101017889851cab-ce60cfdb-d88c-43d8-bbd2-7fbf34a0c912-000000@us-west-2.amazonses.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/tlv320aic32x4.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/soc/codecs/tlv320aic32x4.c ++++ b/sound/soc/codecs/tlv320aic32x4.c +@@ -577,12 +577,12 @@ static const struct regmap_range_cfg aic + .window_start = 0, + .window_len = 128, + .range_min = 0, +- .range_max = AIC32X4_RMICPGAVOL, ++ .range_max = AIC32X4_REFPOWERUP, + }, + }; + + const struct regmap_config aic32x4_regmap_config = { +- .max_register = AIC32X4_RMICPGAVOL, ++ .max_register = AIC32X4_REFPOWERUP, + .ranges = aic32x4_regmap_pages, + .num_ranges = ARRAY_SIZE(aic32x4_regmap_pages), + }; diff --git a/queue-5.12/asoc-tlv320aic32x4-register-clocks-before-registering-component.patch b/queue-5.12/asoc-tlv320aic32x4-register-clocks-before-registering-component.patch new file mode 100644 index 00000000000..36f0de9ffae --- /dev/null +++ b/queue-5.12/asoc-tlv320aic32x4-register-clocks-before-registering-component.patch @@ -0,0 +1,49 @@ +From 1ca1156cfd69530e6b7cb99943baf90c8bd871a5 Mon Sep 17 00:00:00 2001 +From: Annaliese McDermond +Date: Wed, 31 Mar 2021 18:21:38 +0000 +Subject: ASoC: tlv320aic32x4: Register clocks before registering component + +From: Annaliese McDermond + +commit 1ca1156cfd69530e6b7cb99943baf90c8bd871a5 upstream. + +Clock registration must be performed before the component is +registered. aic32x4_component_probe attempts to get all the +clocks right off the bat. If the component is registered before +the clocks there is a race condition where the clocks may not +be registered by the time aic32x4_componet_probe actually runs. + +Fixes: d1c859d314d8 ("ASoC: codec: tlv3204: Increased maximum supported channels") +Cc: stable@vger.kernel.org +Signed-off-by: Annaliese McDermond +Link: https://lore.kernel.org/r/0101017889850206-dcac4cce-8cc8-4a21-80e9-4e4bef44b981-000000@us-west-2.amazonses.com +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/codecs/tlv320aic32x4.c | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/sound/soc/codecs/tlv320aic32x4.c ++++ b/sound/soc/codecs/tlv320aic32x4.c +@@ -1243,6 +1243,10 @@ int aic32x4_probe(struct device *dev, st + if (ret) + goto err_disable_regulators; + ++ ret = aic32x4_register_clocks(dev, aic32x4->mclk_name); ++ if (ret) ++ goto err_disable_regulators; ++ + ret = devm_snd_soc_register_component(dev, + &soc_component_dev_aic32x4, &aic32x4_dai, 1); + if (ret) { +@@ -1250,10 +1254,6 @@ int aic32x4_probe(struct device *dev, st + goto err_disable_regulators; + } + +- ret = aic32x4_register_clocks(dev, aic32x4->mclk_name); +- if (ret) +- goto err_disable_regulators; +- + return 0; + + err_disable_regulators: diff --git a/queue-5.12/async_xor-increase-src_offs-when-dropping-destination-page.patch b/queue-5.12/async_xor-increase-src_offs-when-dropping-destination-page.patch new file mode 100644 index 00000000000..96ae201fb04 --- /dev/null +++ b/queue-5.12/async_xor-increase-src_offs-when-dropping-destination-page.patch @@ -0,0 +1,45 @@ +From ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 Mon Sep 17 00:00:00 2001 +From: Xiao Ni +Date: Sun, 25 Apr 2021 17:22:57 +0800 +Subject: async_xor: increase src_offs when dropping destination page + +From: Xiao Ni + +commit ceaf2966ab082bbc4d26516f97b3ca8a676e2af8 upstream. + +Now we support sharing one page if PAGE_SIZE is not equal stripe size. To +support this, it needs to support calculating xor value with different +offsets for each r5dev. One offset array is used to record those offsets. + +In RMW mode, parity page is used as a source page. It sets +ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. +So it needs to add src_list and src_offs at the same time. Now it only +needs src_list. So the xor value which is calculated is wrong. It can +cause data corruption problem. + +I can reproduce this problem 100% on a POWER8 machine. The steps are: + + mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --size=3G + mkfs.xfs /dev/md0 + mount /dev/md0 /mnt/test + mount: /mnt/test: mount(2) system call failed: Structure needs cleaning. + +Fixes: 29bcff787a25 ("md/raid5: add new xor function to support different page offset") +Cc: stable@vger.kernel.org # v5.10+ +Signed-off-by: Xiao Ni +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + crypto/async_tx/async_xor.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/crypto/async_tx/async_xor.c ++++ b/crypto/async_tx/async_xor.c +@@ -233,6 +233,7 @@ async_xor_offs(struct page *dest, unsign + if (submit->flags & ASYNC_TX_XOR_DROP_DST) { + src_cnt--; + src_list++; ++ src_offs++; + } + + /* wait for any prerequisite operations */ diff --git a/queue-5.12/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch b/queue-5.12/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch new file mode 100644 index 00000000000..3853982c341 --- /dev/null +++ b/queue-5.12/fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch @@ -0,0 +1,193 @@ +From f626ca682912fab55dff15469ce893ae16b65c7e Mon Sep 17 00:00:00 2001 +From: "Maciej W. Rozycki" +Date: Wed, 10 Mar 2021 13:03:09 +0100 +Subject: FDDI: defxx: Bail out gracefully with unassigned PCI resource for CSR + +From: Maciej W. Rozycki + +commit f626ca682912fab55dff15469ce893ae16b65c7e upstream. + +Recent versions of the PCI Express specification have deprecated support +for I/O transactions and actually some PCIe host bridges, such as Power +Systems Host Bridge 4 (PHB4), do not implement them. + +For those systems the PCI BARs that request a mapping in the I/O space +have the length recorded in the corresponding PCI resource set to zero, +which makes it unassigned: + +# lspci -s 0031:02:04.0 -v +0031:02:04.0 FDDI network controller: Digital Equipment Corporation PCI-to-PDQ Interface Chip [PFI] FDDI (DEFPA) (rev 02) + Subsystem: Digital Equipment Corporation FDDIcontroller/PCI (DEFPA) + Flags: bus master, medium devsel, latency 136, IRQ 57, NUMA node 8 + Memory at 620c080020000 (32-bit, non-prefetchable) [size=128] + I/O ports at [disabled] + Memory at 620c080030000 (32-bit, non-prefetchable) [size=64K] + Capabilities: [50] Power Management version 2 + Kernel driver in use: defxx + Kernel modules: defxx + +# + +Regardless the driver goes ahead and requests it (here observed with a +Raptor Talos II POWER9 system), resulting in an odd /proc/ioport entry: + +# cat /proc/ioports +00000000-ffffffffffffffff : 0031:02:04.0 +# + +Furthermore, the system gets confused as the driver actually continues +and pokes at those locations, causing a flood of messages being output +to the system console by the underlying system firmware, like: + +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +defxx 0031:02:04.0: enabling device (0140 -> 0142) +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010000 +IPMI: dropping non severe PEL event +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 +IPMI: dropping non severe PEL event +LPC[000]: Got SYNC no-response error. Error address reg: 0xd0010014 +IPMI: dropping non severe PEL event + +and so on and so on (possibly intermixed actually, as there's no locking +between the kernel and the firmware in console port access with this +particular system, but cleaned up above for clarity), and once some 10k +of such pairs of the latter two messages have been produced an interace +eventually shows up in a useless state: + +0031:02:04.0: DEFPA at I/O addr = 0x0, IRQ = 57, Hardware addr = 00-00-00-00-00-00 + +This was not expected to happen as resource handling was added to the +driver a while ago, because it was not known at that time that a PCI +system would be possible that cannot assign port I/O resources, and +oddly enough `request_region' does not fail, which would have caught it. + +Correct the problem then by checking for the length of zero for the CSR +resource and bail out gracefully refusing to register an interface if +that turns out to be the case, producing messages like: + +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +0031:02:04.0: Cannot use I/O, no address set, aborting +0031:02:04.0: Recompile driver with "CONFIG_DEFXX_MMIO=y" + +Keep the original check for the EISA MMIO resource as implemented, +because in that case the length is hardwired to 0x400 as a consequence +of how the compare/mask address decoding works in the ESIC chip and it +is only the base address that is set to zero if MMIO has been disabled +for the adapter in EISA configuration, which in turn could be a valid +bus address in a legacy-free system implementing PCI, especially for +port I/O. + +Where the EISA MMIO resource has been disabled for the adapter in EISA +configuration this arrangement keeps producing messages like: + +eisa 00:05: EISA: slot 5: DEC3002 detected +defxx: v1.11 2014/07/01 Lawrence V. Stefani and others +00:05: Cannot use MMIO, no address set, aborting +00:05: Recompile driver with "CONFIG_DEFXX_MMIO=n" +00:05: Or run ECU and set adapter's MMIO location + +with the last two lines now swapped for easier handling in the driver. + +There is no need to check for and catch the case of a port I/O resource +not having been assigned for EISA as the adapter uses the slot-specific +I/O space, which gets assigned by how EISA has been specified and maps +directly to the particular slot an option card has been placed in. And +the EISA variant of the adapter has additional registers that are only +accessible via the port I/O space anyway. + +While at it factor out the error message calls into helpers and fix an +argument order bug with the `pr_err' call now in `dfx_register_res_err'. + +Signed-off-by: Maciej W. Rozycki +Fixes: 4d0438e56a8f ("defxx: Clean up DEFEA resource management") +Cc: stable@vger.kernel.org # v3.19+ +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/fddi/defxx.c | 47 ++++++++++++++++++++++++++++++----------------- + 1 file changed, 30 insertions(+), 17 deletions(-) + +--- a/drivers/net/fddi/defxx.c ++++ b/drivers/net/fddi/defxx.c +@@ -495,6 +495,25 @@ static const struct net_device_ops dfx_n + .ndo_set_mac_address = dfx_ctl_set_mac_address, + }; + ++static void dfx_register_res_alloc_err(const char *print_name, bool mmio, ++ bool eisa) ++{ ++ pr_err("%s: Cannot use %s, no address set, aborting\n", ++ print_name, mmio ? "MMIO" : "I/O"); ++ pr_err("%s: Recompile driver with \"CONFIG_DEFXX_MMIO=%c\"\n", ++ print_name, mmio ? 'n' : 'y'); ++ if (eisa && mmio) ++ pr_err("%s: Or run ECU and set adapter's MMIO location\n", ++ print_name); ++} ++ ++static void dfx_register_res_err(const char *print_name, bool mmio, ++ unsigned long start, unsigned long len) ++{ ++ pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, aborting\n", ++ print_name, mmio ? "MMIO" : "I/O", len, start); ++} ++ + /* + * ================ + * = dfx_register = +@@ -568,15 +587,12 @@ static int dfx_register(struct device *b + dev_set_drvdata(bdev, dev); + + dfx_get_bars(bdev, bar_start, bar_len); +- if (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0) { +- pr_err("%s: Cannot use MMIO, no address set, aborting\n", +- print_name); +- pr_err("%s: Run ECU and set adapter's MMIO location\n", +- print_name); +- pr_err("%s: Or recompile driver with \"CONFIG_DEFXX_MMIO=n\"" +- "\n", print_name); ++ if (bar_len[0] == 0 || ++ (dfx_bus_eisa && dfx_use_mmio && bar_start[0] == 0)) { ++ dfx_register_res_alloc_err(print_name, dfx_use_mmio, ++ dfx_bus_eisa); + err = -ENXIO; +- goto err_out; ++ goto err_out_disable; + } + + if (dfx_use_mmio) +@@ -585,18 +601,16 @@ static int dfx_register(struct device *b + else + region = request_region(bar_start[0], bar_len[0], print_name); + if (!region) { +- pr_err("%s: Cannot reserve %s resource 0x%lx @ 0x%lx, " +- "aborting\n", dfx_use_mmio ? "MMIO" : "I/O", print_name, +- (long)bar_len[0], (long)bar_start[0]); ++ dfx_register_res_err(print_name, dfx_use_mmio, ++ bar_start[0], bar_len[0]); + err = -EBUSY; + goto err_out_disable; + } + if (bar_start[1] != 0) { + region = request_region(bar_start[1], bar_len[1], print_name); + if (!region) { +- pr_err("%s: Cannot reserve I/O resource " +- "0x%lx @ 0x%lx, aborting\n", print_name, +- (long)bar_len[1], (long)bar_start[1]); ++ dfx_register_res_err(print_name, 0, ++ bar_start[1], bar_len[1]); + err = -EBUSY; + goto err_out_csr_region; + } +@@ -604,9 +618,8 @@ static int dfx_register(struct device *b + if (bar_start[2] != 0) { + region = request_region(bar_start[2], bar_len[2], print_name); + if (!region) { +- pr_err("%s: Cannot reserve I/O resource " +- "0x%lx @ 0x%lx, aborting\n", print_name, +- (long)bar_len[2], (long)bar_start[2]); ++ dfx_register_res_err(print_name, 0, ++ bar_start[2], bar_len[2]); + err = -EBUSY; + goto err_out_bh_region; + } diff --git a/queue-5.12/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch b/queue-5.12/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch new file mode 100644 index 00000000000..db328701ac7 --- /dev/null +++ b/queue-5.12/iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch @@ -0,0 +1,47 @@ +From 4e102429f3dc62dce546f6107e34a4284634196d Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Sun, 21 Mar 2021 18:29:56 +0000 +Subject: iio:accel:adis16201: Fix wrong axis assignment that prevents loading +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Jonathan Cameron + +commit 4e102429f3dc62dce546f6107e34a4284634196d upstream. + +Whilst running some basic tests as part of writing up the dt-bindings for +this driver (to follow), it became clear it doesn't actually load +currently. + +iio iio:device1: tried to double register : in_incli_x_index +adis16201 spi0.0: Failed to create buffer sysfs interfaces +adis16201: probe of spi0.0 failed with error -16 + +Looks like a cut and paste / update bug. Fixes tag obviously not accurate +but we don't want to bother carry thing back to before the driver moved +out of staging. + +Fixes: 591298e54cea ("Staging: iio: accel: adis16201: Move adis16201 driver out of staging") +Signed-off-by: Jonathan Cameron +Cc: +Cc: Himanshu Jha +Cc: Nuno Sá +Reviewed-by: Alexandru Ardelean +Link: https://lore.kernel.org/r/20210321182956.844652-1-jic23@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/accel/adis16201.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/accel/adis16201.c ++++ b/drivers/iio/accel/adis16201.c +@@ -215,7 +215,7 @@ static const struct iio_chan_spec adis16 + ADIS_AUX_ADC_CHAN(ADIS16201_AUX_ADC_REG, ADIS16201_SCAN_AUX_ADC, 0, 12), + ADIS_INCLI_CHAN(X, ADIS16201_XINCL_OUT_REG, ADIS16201_SCAN_INCLI_X, + BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), +- ADIS_INCLI_CHAN(X, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y, ++ ADIS_INCLI_CHAN(Y, ADIS16201_YINCL_OUT_REG, ADIS16201_SCAN_INCLI_Y, + BIT(IIO_CHAN_INFO_CALIBBIAS), 0, 14), + IIO_CHAN_SOFT_TIMESTAMP(7) + }; diff --git a/queue-5.12/iio-adc-ad7476-fix-remove-handling.patch b/queue-5.12/iio-adc-ad7476-fix-remove-handling.patch new file mode 100644 index 00000000000..70daeb33e00 --- /dev/null +++ b/queue-5.12/iio-adc-ad7476-fix-remove-handling.patch @@ -0,0 +1,58 @@ +From 6baee4bd63f5fdf1716f88e95c21a683e94fe30d Mon Sep 17 00:00:00 2001 +From: Jonathan Cameron +Date: Thu, 1 Apr 2021 18:17:57 +0100 +Subject: iio:adc:ad7476: Fix remove handling + +From: Jonathan Cameron + +commit 6baee4bd63f5fdf1716f88e95c21a683e94fe30d upstream. + +This driver was in an odd half way state between devm based cleanup +and manual cleanup (most of which was missing). +I would guess something went wrong with a rebase or similar. +Anyhow, this basically finishes the job as a precursor to improving +the regulator handling. + +Signed-off-by: Jonathan Cameron +Fixes: 4bb2b8f94ace3 ("iio: adc: ad7476: implement devm_add_action_or_reset") +Cc: Michael Hennerich +Reviewed-by: Alexandru Ardelean +Cc: +Link: https://lore.kernel.org/r/20210401171759.318140-2-jic23@kernel.org +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/adc/ad7476.c | 18 ++++-------------- + 1 file changed, 4 insertions(+), 14 deletions(-) + +--- a/drivers/iio/adc/ad7476.c ++++ b/drivers/iio/adc/ad7476.c +@@ -321,25 +321,15 @@ static int ad7476_probe(struct spi_devic + spi_message_init(&st->msg); + spi_message_add_tail(&st->xfer, &st->msg); + +- ret = iio_triggered_buffer_setup(indio_dev, NULL, +- &ad7476_trigger_handler, NULL); ++ ret = devm_iio_triggered_buffer_setup(&spi->dev, indio_dev, NULL, ++ &ad7476_trigger_handler, NULL); + if (ret) +- goto error_disable_reg; ++ return ret; + + if (st->chip_info->reset) + st->chip_info->reset(st); + +- ret = iio_device_register(indio_dev); +- if (ret) +- goto error_ring_unregister; +- return 0; +- +-error_ring_unregister: +- iio_triggered_buffer_cleanup(indio_dev); +-error_disable_reg: +- regulator_disable(st->reg); +- +- return ret; ++ return devm_iio_device_register(&spi->dev, indio_dev); + } + + static const struct spi_device_id ad7476_id[] = { diff --git a/queue-5.12/iio-hid-sensor-rotation-fix-quaternion-data-not-correct.patch b/queue-5.12/iio-hid-sensor-rotation-fix-quaternion-data-not-correct.patch new file mode 100644 index 00000000000..bf4373d96bc --- /dev/null +++ b/queue-5.12/iio-hid-sensor-rotation-fix-quaternion-data-not-correct.patch @@ -0,0 +1,54 @@ +From 6c3b615379d7cd90d2f70b3cf9860c5a4910546a Mon Sep 17 00:00:00 2001 +From: Ye Xiang +Date: Sat, 30 Jan 2021 18:25:46 +0800 +Subject: iio: hid-sensor-rotation: Fix quaternion data not correct + +From: Ye Xiang + +commit 6c3b615379d7cd90d2f70b3cf9860c5a4910546a upstream. + +Because the data of HID_USAGE_SENSOR_ORIENT_QUATERNION defined by ISH FW +is s16, but quaternion data type is in_rot_quaternion_type(le:s16/32X4>>0), +need to transform data type from s16 to s32 + +May require manual backporting. + +Fixes: fc18dddc0625 ("iio: hid-sensors: Added device rotation support") +Signed-off-by: Ye Xiang +Link: https://lore.kernel.org/r/20210130102546.31397-1-xiang.ye@intel.com +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/orientation/hid-sensor-rotation.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +--- a/drivers/iio/orientation/hid-sensor-rotation.c ++++ b/drivers/iio/orientation/hid-sensor-rotation.c +@@ -21,7 +21,7 @@ struct dev_rot_state { + struct hid_sensor_common common_attributes; + struct hid_sensor_hub_attribute_info quaternion; + struct { +- u32 sampled_vals[4] __aligned(16); ++ s32 sampled_vals[4] __aligned(16); + u64 timestamp __aligned(8); + } scan; + int scale_pre_decml; +@@ -170,8 +170,15 @@ static int dev_rot_capture_sample(struct + struct dev_rot_state *rot_state = iio_priv(indio_dev); + + if (usage_id == HID_USAGE_SENSOR_ORIENT_QUATERNION) { +- memcpy(&rot_state->scan.sampled_vals, raw_data, +- sizeof(rot_state->scan.sampled_vals)); ++ if (raw_len / 4 == sizeof(s16)) { ++ rot_state->scan.sampled_vals[0] = ((s16 *)raw_data)[0]; ++ rot_state->scan.sampled_vals[1] = ((s16 *)raw_data)[1]; ++ rot_state->scan.sampled_vals[2] = ((s16 *)raw_data)[2]; ++ rot_state->scan.sampled_vals[3] = ((s16 *)raw_data)[3]; ++ } else { ++ memcpy(&rot_state->scan.sampled_vals, raw_data, ++ sizeof(rot_state->scan.sampled_vals)); ++ } + + dev_dbg(&indio_dev->dev, "Recd Quat len:%zu::%zu\n", raw_len, + sizeof(rot_state->scan.sampled_vals)); diff --git a/queue-5.12/iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch b/queue-5.12/iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch new file mode 100644 index 00000000000..bb9333bccb8 --- /dev/null +++ b/queue-5.12/iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch @@ -0,0 +1,82 @@ +From e09fe9135399807b8397798a53160e055dc6c29f Mon Sep 17 00:00:00 2001 +From: Lars-Peter Clausen +Date: Mon, 5 Apr 2021 13:44:41 +0200 +Subject: iio: inv_mpu6050: Fully validate gyro and accel scale writes + +From: Lars-Peter Clausen + +commit e09fe9135399807b8397798a53160e055dc6c29f upstream. + +When setting the gyro or accelerometer scale the inv_mpu6050 driver ignores +the integer part of the value. As a result e.g. all of 0.13309, 1.13309, +12345.13309, ... are accepted as a valid gyro scale and 0.13309 is the +scale that gets set in all those cases. + +Make sure to check that the integer part of the scale value is 0 and reject +it otherwise. + +Fixes: 09a642b78523 ("Invensense MPU6050 Device Driver.") +Signed-off-by: Lars-Peter Clausen +Acked-by: Jean-Baptiste Maneyrol +Link: https://lore.kernel.org/r/20210405114441.24167-1-lars@metafoo.de +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/imu/inv_mpu6050/inv_mpu_core.c | 20 ++++++++++++++------ + 1 file changed, 14 insertions(+), 6 deletions(-) + +--- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c ++++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c +@@ -731,12 +731,16 @@ inv_mpu6050_read_raw(struct iio_dev *ind + } + } + +-static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st, int val) ++static int inv_mpu6050_write_gyro_scale(struct inv_mpu6050_state *st, int val, ++ int val2) + { + int result, i; + ++ if (val != 0) ++ return -EINVAL; ++ + for (i = 0; i < ARRAY_SIZE(gyro_scale_6050); ++i) { +- if (gyro_scale_6050[i] == val) { ++ if (gyro_scale_6050[i] == val2) { + result = inv_mpu6050_set_gyro_fsr(st, i); + if (result) + return result; +@@ -767,13 +771,17 @@ static int inv_write_raw_get_fmt(struct + return -EINVAL; + } + +-static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st, int val) ++static int inv_mpu6050_write_accel_scale(struct inv_mpu6050_state *st, int val, ++ int val2) + { + int result, i; + u8 d; + ++ if (val != 0) ++ return -EINVAL; ++ + for (i = 0; i < ARRAY_SIZE(accel_scale); ++i) { +- if (accel_scale[i] == val) { ++ if (accel_scale[i] == val2) { + d = (i << INV_MPU6050_ACCL_CONFIG_FSR_SHIFT); + result = regmap_write(st->map, st->reg->accl_config, d); + if (result) +@@ -814,10 +822,10 @@ static int inv_mpu6050_write_raw(struct + case IIO_CHAN_INFO_SCALE: + switch (chan->type) { + case IIO_ANGL_VEL: +- result = inv_mpu6050_write_gyro_scale(st, val2); ++ result = inv_mpu6050_write_gyro_scale(st, val, val2); + break; + case IIO_ACCEL: +- result = inv_mpu6050_write_accel_scale(st, val2); ++ result = inv_mpu6050_write_accel_scale(st, val, val2); + break; + default: + result = -EINVAL; diff --git a/queue-5.12/iio-magnetometer-yas530-fix-return-value-on-error-path.patch b/queue-5.12/iio-magnetometer-yas530-fix-return-value-on-error-path.patch new file mode 100644 index 00000000000..bc84bce0a0d --- /dev/null +++ b/queue-5.12/iio-magnetometer-yas530-fix-return-value-on-error-path.patch @@ -0,0 +1,35 @@ +From e64837bf9e2c063d6b5bab51c0554a60270f636d Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Mon, 15 Feb 2021 16:30:23 +0100 +Subject: iio: magnetometer: yas530: Fix return value on error path + +From: Linus Walleij + +commit e64837bf9e2c063d6b5bab51c0554a60270f636d upstream. + +There was a missed return variable assignment in the +default errorpath of the switch statement in yas5xx_probe(). +Fix it. + +Reported-by: kernel test robot +Reported-by: Dan Carpenter +Suggested-by: Andy Shevchenko +Signed-off-by: Linus Walleij +Link: https://lore.kernel.org/r/20210215153023.47899-1-linus.walleij@linaro.org +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/magnetometer/yamaha-yas530.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/iio/magnetometer/yamaha-yas530.c ++++ b/drivers/iio/magnetometer/yamaha-yas530.c +@@ -888,6 +888,7 @@ static int yas5xx_probe(struct i2c_clien + strncpy(yas5xx->name, "yas532", sizeof(yas5xx->name)); + break; + default: ++ ret = -ENODEV; + dev_err(dev, "unhandled device ID %02x\n", yas5xx->devid); + goto assert_reset; + } diff --git a/queue-5.12/iio-magnetometer-yas530-include-right-header.patch b/queue-5.12/iio-magnetometer-yas530-include-right-header.patch new file mode 100644 index 00000000000..194a597725e --- /dev/null +++ b/queue-5.12/iio-magnetometer-yas530-include-right-header.patch @@ -0,0 +1,41 @@ +From bb354aeb364f9dee51e16edfdf6194ce4ba9237e Mon Sep 17 00:00:00 2001 +From: Linus Walleij +Date: Mon, 15 Feb 2021 16:30:32 +0100 +Subject: iio: magnetometer: yas530: Include right header + +From: Linus Walleij + +commit bb354aeb364f9dee51e16edfdf6194ce4ba9237e upstream. + +To get access to the big endian byte order parsing helpers +drivers need to include and nothing else. + +Reported-by: kernel test robot +Suggested-by: Harvey Harrison +Signed-off-by: Linus Walleij +Cc: +Link: https://lore.kernel.org/r/20210215153032.47962-1-linus.walleij@linaro.org +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/magnetometer/yamaha-yas530.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/iio/magnetometer/yamaha-yas530.c ++++ b/drivers/iio/magnetometer/yamaha-yas530.c +@@ -32,13 +32,14 @@ + #include + #include + #include +-#include + + #include + #include + #include + #include + ++#include ++ + /* This register map covers YAS530 and YAS532 but differs in YAS 537 and YAS539 */ + #define YAS5XX_DEVICE_ID 0x80 + #define YAS5XX_ACTUATE_INIT_COIL 0x81 diff --git a/queue-5.12/iio-sx9310-fix-access-to-variable-dt-array.patch b/queue-5.12/iio-sx9310-fix-access-to-variable-dt-array.patch new file mode 100644 index 00000000000..4690da41800 --- /dev/null +++ b/queue-5.12/iio-sx9310-fix-access-to-variable-dt-array.patch @@ -0,0 +1,91 @@ +From 6f0078ae704d94b1a93e5f3d0a44cf3d8090fa91 Mon Sep 17 00:00:00 2001 +From: Gwendal Grignou +Date: Fri, 26 Mar 2021 11:46:02 -0700 +Subject: iio: sx9310: Fix access to variable DT array + +From: Gwendal Grignou + +commit 6f0078ae704d94b1a93e5f3d0a44cf3d8090fa91 upstream. + +With the current code, we want to read 4 entries from DT array +"semtech,combined-sensors". If there are less, we silently fail as +of_property_read_u32_array() returns -EOVERFLOW. + +First count the number of entries and if between 1 and 4, collect the +content of the array. + +Fixes: 5b19ca2c78a0 ("iio: sx9310: Set various settings from DT") +Signed-off-by: Gwendal Grignou +Reviewed-by: Andy Shevchenko +Link: https://lore.kernel.org/r/20210326184603.251683-2-gwendal@chromium.org +Cc: +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/proximity/sx9310.c | 40 ++++++++++++++++++++++++++++------------ + 1 file changed, 28 insertions(+), 12 deletions(-) + +--- a/drivers/iio/proximity/sx9310.c ++++ b/drivers/iio/proximity/sx9310.c +@@ -1221,17 +1221,17 @@ static int sx9310_init_compensation(stru + } + + static const struct sx9310_reg_default * +-sx9310_get_default_reg(struct sx9310_data *data, int i, ++sx9310_get_default_reg(struct sx9310_data *data, int idx, + struct sx9310_reg_default *reg_def) + { +- int ret; + const struct device_node *np = data->client->dev.of_node; +- u32 combined[SX9310_NUM_CHANNELS] = { 4, 4, 4, 4 }; ++ u32 combined[SX9310_NUM_CHANNELS]; ++ u32 start = 0, raw = 0, pos = 0; + unsigned long comb_mask = 0; ++ int ret, i, count; + const char *res; +- u32 start = 0, raw = 0, pos = 0; + +- memcpy(reg_def, &sx9310_default_regs[i], sizeof(*reg_def)); ++ memcpy(reg_def, &sx9310_default_regs[idx], sizeof(*reg_def)); + if (!np) + return reg_def; + +@@ -1242,15 +1242,31 @@ sx9310_get_default_reg(struct sx9310_dat + reg_def->def |= SX9310_REG_PROX_CTRL2_SHIELDEN_GROUND; + } + +- reg_def->def &= ~SX9310_REG_PROX_CTRL2_COMBMODE_MASK; +- of_property_read_u32_array(np, "semtech,combined-sensors", +- combined, ARRAY_SIZE(combined)); +- for (i = 0; i < ARRAY_SIZE(combined); i++) { +- if (combined[i] <= SX9310_NUM_CHANNELS) +- comb_mask |= BIT(combined[i]); ++ count = of_property_count_elems_of_size(np, "semtech,combined-sensors", ++ sizeof(u32)); ++ if (count > 0 && count <= ARRAY_SIZE(combined)) { ++ ret = of_property_read_u32_array(np, "semtech,combined-sensors", ++ combined, count); ++ if (ret) ++ break; ++ } else { ++ /* ++ * Either the property does not exist in the DT or the ++ * number of entries is incorrect. ++ */ ++ break; + } ++ for (i = 0; i < count; i++) { ++ if (combined[i] >= SX9310_NUM_CHANNELS) { ++ /* Invalid sensor (invalid DT). */ ++ break; ++ } ++ comb_mask |= BIT(combined[i]); ++ } ++ if (i < count) ++ break; + +- comb_mask &= 0xf; ++ reg_def->def &= ~SX9310_REG_PROX_CTRL2_COMBMODE_MASK; + if (comb_mask == (BIT(3) | BIT(2) | BIT(1) | BIT(0))) + reg_def->def |= SX9310_REG_PROX_CTRL2_COMBMODE_CS0_CS1_CS2_CS3; + else if (comb_mask == (BIT(1) | BIT(2))) diff --git a/queue-5.12/iio-sx9310-fix-write_.._debounce.patch b/queue-5.12/iio-sx9310-fix-write_.._debounce.patch new file mode 100644 index 00000000000..89d32e335fb --- /dev/null +++ b/queue-5.12/iio-sx9310-fix-write_.._debounce.patch @@ -0,0 +1,61 @@ +From fc948409ccc1e8afe8655cee77c686eedbfbee60 Mon Sep 17 00:00:00 2001 +From: Gwendal Grignou +Date: Wed, 31 Mar 2021 11:22:22 -0700 +Subject: iio: sx9310: Fix write_.._debounce() + +From: Gwendal Grignou + +commit fc948409ccc1e8afe8655cee77c686eedbfbee60 upstream. + +Check input to be sure it matches Semtech sx9310 specification and +can fit into debounce register. +Compare argument writen to thresh_.._period with read from same +sysfs attribute: + +Before: Afer: +write | read write | read +-1 | 8 -1 fails: -EINVAL +0 | 8 0 | 0 +1 | 0 1 | 0 +2..15 | 2^log2(N) 2..15 | 2^log2(N) +16 | 0 >= 16 fails: -EINVAL + +Fixes: 1b6872015f0b ("iio: sx9310: Support setting debounce values") +Signed-off-by: Gwendal Grignou +Cc: stable@vger.kernel.org +Reviewed-by: Stephen Boyd +Link: https://lore.kernel.org/r/20210331182222.219533-1-gwendal@chromium.org +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/proximity/sx9310.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +--- a/drivers/iio/proximity/sx9310.c ++++ b/drivers/iio/proximity/sx9310.c +@@ -763,7 +763,11 @@ static int sx9310_write_far_debounce(str + int ret; + unsigned int regval; + +- val = ilog2(val); ++ if (val > 0) ++ val = ilog2(val); ++ if (!FIELD_FIT(SX9310_REG_PROX_CTRL10_FAR_DEBOUNCE_MASK, val)) ++ return -EINVAL; ++ + regval = FIELD_PREP(SX9310_REG_PROX_CTRL10_FAR_DEBOUNCE_MASK, val); + + mutex_lock(&data->mutex); +@@ -780,7 +784,11 @@ static int sx9310_write_close_debounce(s + int ret; + unsigned int regval; + +- val = ilog2(val); ++ if (val > 0) ++ val = ilog2(val); ++ if (!FIELD_FIT(SX9310_REG_PROX_CTRL10_CLOSE_DEBOUNCE_MASK, val)) ++ return -EINVAL; ++ + regval = FIELD_PREP(SX9310_REG_PROX_CTRL10_CLOSE_DEBOUNCE_MASK, val); + + mutex_lock(&data->mutex); diff --git a/queue-5.12/kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch b/queue-5.12/kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch new file mode 100644 index 00000000000..7aa59c14d7e --- /dev/null +++ b/queue-5.12/kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch @@ -0,0 +1,38 @@ +From f66c53b3b94f658590e1012bf6d922f8b7e01bda Mon Sep 17 00:00:00 2001 +From: Sean Christopherson +Date: Thu, 4 Mar 2021 17:10:58 -0800 +Subject: KVM: x86: Defer the MMU unload to the normal path on an global INVPCID + +From: Sean Christopherson + +commit f66c53b3b94f658590e1012bf6d922f8b7e01bda upstream. + +Defer unloading the MMU after a INVPCID until the instruction emulation +has completed, i.e. until after RIP has been updated. + +On VMX, this is a benign bug as VMX doesn't touch the MMU when skipping +an emulated instruction. However, on SVM, if nrip is disabled, the +emulator is used to skip an instruction, which would lead to fireworks +if the emulator were invoked without a valid MMU. + +Fixes: eb4b248e152d ("kvm: vmx: Support INVPCID in shadow paging mode") +Cc: stable@vger.kernel.org +Signed-off-by: Sean Christopherson +Message-Id: <20210305011101.3597423-15-seanjc@google.com> +Signed-off-by: Paolo Bonzini +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kvm/x86.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kvm/x86.c ++++ b/arch/x86/kvm/x86.c +@@ -11539,7 +11539,7 @@ int kvm_handle_invpcid(struct kvm_vcpu * + + fallthrough; + case INVPCID_TYPE_ALL_INCL_GLOBAL: +- kvm_mmu_unload(vcpu); ++ kvm_make_request(KVM_REQ_MMU_RELOAD, vcpu); + return kvm_skip_emulated_instruction(vcpu); + + default: diff --git a/queue-5.12/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch b/queue-5.12/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch new file mode 100644 index 00000000000..35cf2596d18 --- /dev/null +++ b/queue-5.12/md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch @@ -0,0 +1,105 @@ +From 404a8ef512587b2460107d3272c17a89aef75edf Mon Sep 17 00:00:00 2001 +From: Sudhakar Panneerselvam +Date: Tue, 13 Apr 2021 04:08:29 +0000 +Subject: md/bitmap: wait for external bitmap writes to complete during tear down + +From: Sudhakar Panneerselvam + +commit 404a8ef512587b2460107d3272c17a89aef75edf upstream. + +NULL pointer dereference was observed in super_written() when it tries +to access the mddev structure. + +[The below stack trace is from an older kernel, but the problem described +in this patch applies to the mainline kernel.] + +[ 1194.474861] task: ffff8fdd20858000 task.stack: ffffb99d40790000 +[ 1194.488000] RIP: 0010:super_written+0x29/0xe1 +[ 1194.499688] RSP: 0018:ffff8ffb7fcc3c78 EFLAGS: 00010046 +[ 1194.512477] RAX: 0000000000000000 RBX: ffff8ffb7bf4a000 RCX: ffff8ffb78991048 +[ 1194.527325] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff8ffb56b8a200 +[ 1194.542576] RBP: ffff8ffb7fcc3c90 R08: 000000000000000b R09: 0000000000000000 +[ 1194.558001] R10: ffff8ffb56b8a298 R11: 0000000000000000 R12: ffff8ffb56b8a200 +[ 1194.573070] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 +[ 1194.588117] FS: 0000000000000000(0000) GS:ffff8ffb7fcc0000(0000) knlGS:0000000000000000 +[ 1194.604264] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +[ 1194.617375] CR2: 00000000000002b8 CR3: 00000021e040a002 CR4: 00000000007606e0 +[ 1194.632327] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +[ 1194.647865] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +[ 1194.663316] PKRU: 55555554 +[ 1194.674090] Call Trace: +[ 1194.683735] +[ 1194.692948] bio_endio+0xae/0x135 +[ 1194.703580] blk_update_request+0xad/0x2fa +[ 1194.714990] blk_update_bidi_request+0x20/0x72 +[ 1194.726578] __blk_end_bidi_request+0x2c/0x4d +[ 1194.738373] __blk_end_request_all+0x31/0x49 +[ 1194.749344] blk_flush_complete_seq+0x377/0x383 +[ 1194.761550] flush_end_io+0x1dd/0x2a7 +[ 1194.772910] blk_finish_request+0x9f/0x13c +[ 1194.784544] scsi_end_request+0x180/0x25c +[ 1194.796149] scsi_io_completion+0xc8/0x610 +[ 1194.807503] scsi_finish_command+0xdc/0x125 +[ 1194.818897] scsi_softirq_done+0x81/0xde +[ 1194.830062] blk_done_softirq+0xa4/0xcc +[ 1194.841008] __do_softirq+0xd9/0x29f +[ 1194.851257] irq_exit+0xe6/0xeb +[ 1194.861290] do_IRQ+0x59/0xe3 +[ 1194.871060] common_interrupt+0x1c6/0x382 +[ 1194.881988] +[ 1194.890646] RIP: 0010:cpuidle_enter_state+0xdd/0x2a5 +[ 1194.902532] RSP: 0018:ffffb99d40793e68 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff43 +[ 1194.917317] RAX: ffff8ffb7fce27c0 RBX: ffff8ffb7fced800 RCX: 000000000000001f +[ 1194.932056] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000000 +[ 1194.946428] RBP: ffffb99d40793ea0 R08: 0000000000000004 R09: 0000000000002ed2 +[ 1194.960508] R10: 0000000000002664 R11: 0000000000000018 R12: 0000000000000003 +[ 1194.974454] R13: 000000000000000b R14: ffffffff925715a0 R15: 0000011610120d5a +[ 1194.988607] ? cpuidle_enter_state+0xcc/0x2a5 +[ 1194.999077] cpuidle_enter+0x17/0x19 +[ 1195.008395] call_cpuidle+0x23/0x3a +[ 1195.017718] do_idle+0x172/0x1d5 +[ 1195.026358] cpu_startup_entry+0x73/0x75 +[ 1195.035769] start_secondary+0x1b9/0x20b +[ 1195.044894] secondary_startup_64+0xa5/0xa5 +[ 1195.084921] RIP: super_written+0x29/0xe1 RSP: ffff8ffb7fcc3c78 +[ 1195.096354] CR2: 00000000000002b8 + +bio in the above stack is a bitmap write whose completion is invoked after +the tear down sequence sets the mddev structure to NULL in rdev. + +During tear down, there is an attempt to flush the bitmap writes, but for +external bitmaps, there is no explicit wait for all the bitmap writes to +complete. For instance, md_bitmap_flush() is called to flush the bitmap +writes, but the last call to md_bitmap_daemon_work() in md_bitmap_flush() +could generate new bitmap writes for which there is no explicit wait to +complete those writes. The call to md_bitmap_update_sb() will return +simply for external bitmaps and the follow-up call to md_update_sb() is +conditional and may not get called for external bitmaps. This results in a +kernel panic when the completion routine, super_written() is called which +tries to reference mddev in the rdev that has been set to +NULL(in unbind_rdev_from_array() by tear down sequence). + +The solution is to call md_super_wait() for external bitmaps after the +last call to md_bitmap_daemon_work() in md_bitmap_flush() to ensure there +are no pending bitmap writes before proceeding with the tear down. + +Cc: stable@vger.kernel.org +Signed-off-by: Sudhakar Panneerselvam +Reviewed-by: Zhao Heming +Signed-off-by: Song Liu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/md-bitmap.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/md/md-bitmap.c ++++ b/drivers/md/md-bitmap.c +@@ -1722,6 +1722,8 @@ void md_bitmap_flush(struct mddev *mddev + md_bitmap_daemon_work(mddev); + bitmap->daemon_lastrun -= sleep; + md_bitmap_daemon_work(mddev); ++ if (mddev->bitmap_info.external) ++ md_super_wait(mddev); + md_bitmap_update_sb(bitmap); + } + diff --git a/queue-5.12/mips-pci-mt7620-fix-pll-lock-check.patch b/queue-5.12/mips-pci-mt7620-fix-pll-lock-check.patch new file mode 100644 index 00000000000..ffbec9b756d --- /dev/null +++ b/queue-5.12/mips-pci-mt7620-fix-pll-lock-check.patch @@ -0,0 +1,55 @@ +From c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Sat, 6 Mar 2021 20:17:24 -0800 +Subject: MIPS: pci-mt7620: fix PLL lock check + +From: Ilya Lipnitskiy + +commit c15b99ae2ba9ea30da3c7cd4765b8a4707e530a6 upstream. + +Upstream a long-standing OpenWrt patch [0] that fixes MT7620 PCIe PLL +lock check. The existing code checks the wrong register bit: PPLL_SW_SET +is not defined in PPLL_CFG1 and bit 31 of PPLL_CFG1 is marked as reserved +in the MT7620 Programming Guide. The correct bit to check for PLL lock +is PPLL_LD (bit 23). + +Also reword the error message for clarity. + +Without this change it is unlikely that this driver ever worked with +mainline kernel. + +[0]: https://lists.infradead.org/pipermail/lede-commits/2017-July/004441.html + +Signed-off-by: Ilya Lipnitskiy +Cc: John Crispin +Cc: linux-mips@vger.kernel.org +Cc: linux-mediatek@lists.infradead.org +Cc: linux-kernel@vger.kernel.org +Cc: stable@vger.kernel.org +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/pci/pci-mt7620.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/arch/mips/pci/pci-mt7620.c ++++ b/arch/mips/pci/pci-mt7620.c +@@ -30,6 +30,7 @@ + #define RALINK_GPIOMODE 0x60 + + #define PPLL_CFG1 0x9c ++#define PPLL_LD BIT(23) + + #define PPLL_DRV 0xa0 + #define PDRV_SW_SET BIT(31) +@@ -239,8 +240,8 @@ static int mt7620_pci_hw_init(struct pla + rt_sysc_m32(0, RALINK_PCIE0_CLK_EN, RALINK_CLKCFG1); + mdelay(100); + +- if (!(rt_sysc_r32(PPLL_CFG1) & PDRV_SW_SET)) { +- dev_err(&pdev->dev, "MT7620 PPLL unlock\n"); ++ if (!(rt_sysc_r32(PPLL_CFG1) & PPLL_LD)) { ++ dev_err(&pdev->dev, "pcie PLL not locked, aborting init\n"); + reset_control_assert(rstpcie0); + rt_sysc_m32(RALINK_PCIE0_CLK_EN, 0, RALINK_CLKCFG1); + return -1; diff --git a/queue-5.12/mips-pci-rt2880-fix-slot-0-configuration.patch b/queue-5.12/mips-pci-rt2880-fix-slot-0-configuration.patch new file mode 100644 index 00000000000..9652bddcfcf --- /dev/null +++ b/queue-5.12/mips-pci-rt2880-fix-slot-0-configuration.patch @@ -0,0 +1,104 @@ +From 8e98b697006d749d745d3b174168a877bb96c500 Mon Sep 17 00:00:00 2001 +From: Ilya Lipnitskiy +Date: Tue, 13 Apr 2021 20:12:33 -0700 +Subject: MIPS: pci-rt2880: fix slot 0 configuration + +From: Ilya Lipnitskiy + +commit 8e98b697006d749d745d3b174168a877bb96c500 upstream. + +pci_fixup_irqs() used to call pcibios_map_irq on every PCI device, which +for RT2880 included bus 0 slot 0. After pci_fixup_irqs() got removed, +only slots/funcs with devices attached would be called. While arguably +the right thing, that left no chance for this driver to ever initialize +slot 0, effectively bricking PCI and USB on RT2880 devices such as the +Belkin F5D8235-4 v1. + +Slot 0 configuration needs to happen after PCI bus enumeration, but +before any device at slot 0x11 (func 0 or 1) is talked to. That was +determined empirically by testing on a Belkin F5D8235-4 v1 device. A +minimal BAR 0 config write followed by read, then setting slot 0 +PCI_COMMAND to MASTER | IO | MEMORY is all that seems to be required for +proper functionality. + +Tested by ensuring that full- and high-speed USB devices get enumerated +on the Belkin F5D8235-4 v1 (with an out of tree DTS file from OpenWrt). + +Fixes: 04c81c7293df ("MIPS: PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") +Signed-off-by: Ilya Lipnitskiy +Cc: Lorenzo Pieralisi +Cc: Tobias Wolf +Cc: # v4.14+ +Signed-off-by: Thomas Bogendoerfer +Signed-off-by: Greg Kroah-Hartman +--- + arch/mips/pci/pci-rt2880.c | 37 ++++++++++++++++++++++++------------- + 1 file changed, 24 insertions(+), 13 deletions(-) + +--- a/arch/mips/pci/pci-rt2880.c ++++ b/arch/mips/pci/pci-rt2880.c +@@ -180,7 +180,6 @@ static inline void rt2880_pci_write_u32( + + int pcibios_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) + { +- u16 cmd; + int irq = -1; + + if (dev->bus->number != 0) +@@ -188,8 +187,6 @@ int pcibios_map_irq(const struct pci_dev + + switch (PCI_SLOT(dev->devfn)) { + case 0x00: +- rt2880_pci_write_u32(PCI_BASE_ADDRESS_0, 0x08000000); +- (void) rt2880_pci_read_u32(PCI_BASE_ADDRESS_0); + break; + case 0x11: + irq = RT288X_CPU_IRQ_PCI; +@@ -201,16 +198,6 @@ int pcibios_map_irq(const struct pci_dev + break; + } + +- pci_write_config_byte((struct pci_dev *) dev, +- PCI_CACHE_LINE_SIZE, 0x14); +- pci_write_config_byte((struct pci_dev *) dev, PCI_LATENCY_TIMER, 0xFF); +- pci_read_config_word((struct pci_dev *) dev, PCI_COMMAND, &cmd); +- cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY | +- PCI_COMMAND_INVALIDATE | PCI_COMMAND_FAST_BACK | +- PCI_COMMAND_SERR | PCI_COMMAND_WAIT | PCI_COMMAND_PARITY; +- pci_write_config_word((struct pci_dev *) dev, PCI_COMMAND, cmd); +- pci_write_config_byte((struct pci_dev *) dev, PCI_INTERRUPT_LINE, +- dev->irq); + return irq; + } + +@@ -251,6 +238,30 @@ static int rt288x_pci_probe(struct platf + + int pcibios_plat_dev_init(struct pci_dev *dev) + { ++ static bool slot0_init; ++ ++ /* ++ * Nobody seems to initialize slot 0, but this platform requires it, so ++ * do it once when some other slot is being enabled. The PCI subsystem ++ * should configure other slots properly, so no need to do anything ++ * special for those. ++ */ ++ if (!slot0_init && dev->bus->number == 0) { ++ u16 cmd; ++ u32 bar0; ++ ++ slot0_init = true; ++ ++ pci_bus_write_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0, ++ 0x08000000); ++ pci_bus_read_config_dword(dev->bus, 0, PCI_BASE_ADDRESS_0, ++ &bar0); ++ ++ pci_bus_read_config_word(dev->bus, 0, PCI_COMMAND, &cmd); ++ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_IO | PCI_COMMAND_MEMORY; ++ pci_bus_write_config_word(dev->bus, 0, PCI_COMMAND, cmd); ++ } ++ + return 0; + } + diff --git a/queue-5.12/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch b/queue-5.12/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch new file mode 100644 index 00000000000..fb3c4cc6b4c --- /dev/null +++ b/queue-5.12/misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch @@ -0,0 +1,101 @@ +From 3641762c1c9c7cfd84a7061a0a73054f09b412e3 Mon Sep 17 00:00:00 2001 +From: Hans de Goede +Date: Wed, 17 Feb 2021 11:24:59 +0100 +Subject: misc: lis3lv02d: Fix false-positive WARN on various HP models + +From: Hans de Goede + +commit 3641762c1c9c7cfd84a7061a0a73054f09b412e3 upstream. + +Before this commit lis3lv02d_get_pwron_wait() had a WARN_ONCE() to catch +a potential divide by 0. WARN macros should only be used to catch internal +kernel bugs and that is not the case here. We have been receiving a lot of +bug reports about kernel backtraces caused by this WARN. + +The div value being checked comes from the lis3->odrs[] array. Which +is sized to be a power-of-2 matching the number of bits in lis3->odr_mask. + +The only lis3 model where this array is not entirely filled with non zero +values. IOW the only model where we can hit the div == 0 check is the +3dc ("8 bits 3DC sensor") model: + +int lis3_3dc_rates[16] = {0, 1, 10, 25, 50, 100, 200, 400, 1600, 5000}; + +Note the 0 value at index 0, according to the datasheet an odr index of 0 +means "Power-down mode". HP typically uses a lis3 accelerometer for HDD +fall protection. What I believe is happening here is that on newer +HP devices, which only contain a SDD, the BIOS is leaving the lis3 device +powered-down since it is not used for HDD fall protection. + +Note that the lis3_3dc_rates array initializer only specifies 10 values, +which matches the datasheet. So it also contains 6 zero values at the end. + +Replace the WARN with a normal check, which treats an odr index of 0 +as power-down and uses a normal dev_err() to report the error in case +odr index point past the initialized part of the array. + +Fixes: 1510dd5954be ("lis3lv02d: avoid divide by zero due to unchecked") +Cc: stable@vger.kernel.org +Signed-off-by: Hans de Goede +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=785814 +BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1817027 +BugLink: https://bugs.centos.org/view.php?id=10720 +Link: https://lore.kernel.org/r/20210217102501.31758-1-hdegoede@redhat.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/lis3lv02d/lis3lv02d.c | 21 ++++++++++++++++----- + 1 file changed, 16 insertions(+), 5 deletions(-) + +--- a/drivers/misc/lis3lv02d/lis3lv02d.c ++++ b/drivers/misc/lis3lv02d/lis3lv02d.c +@@ -208,7 +208,7 @@ static int lis3_3dc_rates[16] = {0, 1, 1 + static int lis3_3dlh_rates[4] = {50, 100, 400, 1000}; + + /* ODR is Output Data Rate */ +-static int lis3lv02d_get_odr(struct lis3lv02d *lis3) ++static int lis3lv02d_get_odr_index(struct lis3lv02d *lis3) + { + u8 ctrl; + int shift; +@@ -216,15 +216,23 @@ static int lis3lv02d_get_odr(struct lis3 + lis3->read(lis3, CTRL_REG1, &ctrl); + ctrl &= lis3->odr_mask; + shift = ffs(lis3->odr_mask) - 1; +- return lis3->odrs[(ctrl >> shift)]; ++ return (ctrl >> shift); + } + + static int lis3lv02d_get_pwron_wait(struct lis3lv02d *lis3) + { +- int div = lis3lv02d_get_odr(lis3); ++ int odr_idx = lis3lv02d_get_odr_index(lis3); ++ int div = lis3->odrs[odr_idx]; + +- if (WARN_ONCE(div == 0, "device returned spurious data")) ++ if (div == 0) { ++ if (odr_idx == 0) { ++ /* Power-down mode, not sampling no need to sleep */ ++ return 0; ++ } ++ ++ dev_err(&lis3->pdev->dev, "Error unknown odrs-index: %d\n", odr_idx); + return -ENXIO; ++ } + + /* LIS3 power on delay is quite long */ + msleep(lis3->pwron_delay / div); +@@ -816,9 +824,12 @@ static ssize_t lis3lv02d_rate_show(struc + struct device_attribute *attr, char *buf) + { + struct lis3lv02d *lis3 = dev_get_drvdata(dev); ++ int odr_idx; + + lis3lv02d_sysfs_poweron(lis3); +- return sprintf(buf, "%d\n", lis3lv02d_get_odr(lis3)); ++ ++ odr_idx = lis3lv02d_get_odr_index(lis3); ++ return sprintf(buf, "%d\n", lis3->odrs[odr_idx]); + } + + static ssize_t lis3lv02d_rate_set(struct device *dev, diff --git a/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch b/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch new file mode 100644 index 00000000000..3b44c553af3 --- /dev/null +++ b/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch @@ -0,0 +1,92 @@ +From b2192cfeba8481224da0a4ec3b4a7ccd80b1623b Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Fri, 2 Apr 2021 21:17:42 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_datagram payload + +From: Tetsuo Handa + +commit b2192cfeba8481224da0a4ec3b4a7ccd80b1623b upstream. + +KMSAN complains that vmci_check_host_caps() left the payload part of +check_msg uninitialized. + + ===================================================== + BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 + CPU: 1 PID: 1 Comm: swapper/0 Tainted: G B 5.11.0-rc7+ #4 + Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 + Call Trace: + dump_stack+0x21c/0x280 + kmsan_report+0xfb/0x1e0 + kmsan_internal_check_memory+0x202/0x520 + kmsan_check_memory+0xd/0x10 + iowrite8_rep+0x86/0x380 + vmci_guest_probe_device+0xf0b/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Uninit was created at: + kmsan_internal_poison_shadow+0x5c/0xf0 + kmsan_slab_alloc+0x8d/0xe0 + kmem_cache_alloc+0x84f/0xe30 + vmci_guest_probe_device+0xd11/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Bytes 28-31 of 36 are uninitialized + Memory access of size 36 starts at ffff8881675e5f00 + ===================================================== + +Fixes: 1f166439917b69d3 ("VMCI: guest side driver implementation.") +Cc: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-2-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_guest.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/vmw_vmci/vmci_guest.c ++++ b/drivers/misc/vmw_vmci/vmci_guest.c +@@ -168,7 +168,7 @@ static int vmci_check_host_caps(struct p + VMCI_UTIL_NUM_RESOURCES * sizeof(u32); + struct vmci_datagram *check_msg; + +- check_msg = kmalloc(msg_size, GFP_KERNEL); ++ check_msg = kzalloc(msg_size, GFP_KERNEL); + if (!check_msg) { + dev_err(&pdev->dev, "%s: Insufficient memory\n", __func__); + return -ENOMEM; diff --git a/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch b/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch new file mode 100644 index 00000000000..d035213a65d --- /dev/null +++ b/queue-5.12/misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch @@ -0,0 +1,74 @@ +From 376565b9717c30cd58ad33860fa42697615fa2e4 Mon Sep 17 00:00:00 2001 +From: Tetsuo Handa +Date: Fri, 2 Apr 2021 21:17:41 +0900 +Subject: misc: vmw_vmci: explicitly initialize vmci_notify_bm_set_msg struct + +From: Tetsuo Handa + +commit 376565b9717c30cd58ad33860fa42697615fa2e4 upstream. + +KMSAN complains that the vmci_use_ppn64() == false path in +vmci_dbell_register_notification_bitmap() left upper 32bits of +bitmap_set_msg.bitmap_ppn64 member uninitialized. + + ===================================================== + BUG: KMSAN: uninit-value in kmsan_check_memory+0xd/0x10 + CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.11.0-rc7+ #4 + Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 02/27/2020 + Call Trace: + dump_stack+0x21c/0x280 + kmsan_report+0xfb/0x1e0 + kmsan_internal_check_memory+0x484/0x520 + kmsan_check_memory+0xd/0x10 + iowrite8_rep+0x86/0x380 + vmci_send_datagram+0x150/0x280 + vmci_dbell_register_notification_bitmap+0x133/0x1e0 + vmci_guest_probe_device+0xcab/0x1e70 + pci_device_probe+0xab3/0xe70 + really_probe+0xd16/0x24d0 + driver_probe_device+0x29d/0x3a0 + device_driver_attach+0x25a/0x490 + __driver_attach+0x78c/0x840 + bus_for_each_dev+0x210/0x340 + driver_attach+0x89/0xb0 + bus_add_driver+0x677/0xc40 + driver_register+0x485/0x8e0 + __pci_register_driver+0x1ff/0x350 + vmci_guest_init+0x3e/0x41 + vmci_drv_init+0x1d6/0x43f + do_one_initcall+0x39c/0x9a0 + do_initcall_level+0x1d7/0x259 + do_initcalls+0x127/0x1cb + do_basic_setup+0x33/0x36 + kernel_init_freeable+0x29a/0x3ed + kernel_init+0x1f/0x840 + ret_from_fork+0x1f/0x30 + + Local variable ----bitmap_set_msg@vmci_dbell_register_notification_bitmap created at: + vmci_dbell_register_notification_bitmap+0x50/0x1e0 + vmci_dbell_register_notification_bitmap+0x50/0x1e0 + + Bytes 28-31 of 32 are uninitialized + Memory access of size 32 starts at ffff88810098f570 + ===================================================== + +Fixes: 83e2ec765be03e8a ("VMCI: doorbell implementation.") +Cc: +Signed-off-by: Tetsuo Handa +Link: https://lore.kernel.org/r/20210402121742.3917-1-penguin-kernel@I-love.SAKURA.ne.jp +Signed-off-by: Greg Kroah-Hartman +--- + drivers/misc/vmw_vmci/vmci_doorbell.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/misc/vmw_vmci/vmci_doorbell.c ++++ b/drivers/misc/vmw_vmci/vmci_doorbell.c +@@ -326,7 +326,7 @@ int vmci_dbell_host_context_notify(u32 s + bool vmci_dbell_register_notification_bitmap(u64 bitmap_ppn) + { + int result; +- struct vmci_notify_bm_set_msg bitmap_set_msg; ++ struct vmci_notify_bm_set_msg bitmap_set_msg = { }; + + bitmap_set_msg.hdr.dst = vmci_make_handle(VMCI_HYPERVISOR_CONTEXT_ID, + VMCI_SET_NOTIFY_BITMAP); diff --git a/queue-5.12/pci-allow-vpd-access-for-qlogic-isp2722.patch b/queue-5.12/pci-allow-vpd-access-for-qlogic-isp2722.patch new file mode 100644 index 00000000000..b93536ef40c --- /dev/null +++ b/queue-5.12/pci-allow-vpd-access-for-qlogic-isp2722.patch @@ -0,0 +1,45 @@ +From e00dc69b5f17c444a38cd9745a0f76bc989b3af4 Mon Sep 17 00:00:00 2001 +From: Arun Easi +Date: Fri, 9 Apr 2021 14:51:53 -0700 +Subject: PCI: Allow VPD access for QLogic ISP2722 + +From: Arun Easi + +commit e00dc69b5f17c444a38cd9745a0f76bc989b3af4 upstream. + +0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") disabled access +to VPD of the ISP2722-based 16/32Gb Fibre Channel to PCIe Adapter because +reading past the end of the VPD caused NMIs. + +104daa71b396 ("PCI: Determine actual VPD size on first access") limits +reads to the actual size of VPD, which should prevent these NMIs. + +104daa71b396 was merged *before* 0d5370d1d852, but we think the testing +that prompted 0d5370d1d852 ("PCI: Prevent VPD access for QLogic ISP2722") +was done with a kernel that lacked 104daa71b396. See [1, 2]. + +Remove the quirk added by 0d5370d1d852 ("PCI: Prevent VPD access for QLogic +ISP2722") so customers can read the HBA VPD. + +[1] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2012161641230.28924@irv1user01.caveonetworks.com/ +[2] https://lore.kernel.org/linux-pci/alpine.LRH.2.21.9999.2104071535110.13940@irv1user01.caveonetworks.com/ +[bhelgaas: commit log] +Link: https://lore.kernel.org/r/20210409215153.16569-2-aeasi@marvell.com +Signed-off-by: Arun Easi +Signed-off-by: Bjorn Helgaas +Cc: stable@vger.kernel.org # v4.6+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/vpd.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/pci/vpd.c ++++ b/drivers/pci/vpd.c +@@ -570,7 +570,6 @@ DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LS + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_LSI_LOGIC, 0x005f, quirk_blacklist_vpd); + DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATTANSIC, PCI_ANY_ID, + quirk_blacklist_vpd); +-DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_QLOGIC, 0x2261, quirk_blacklist_vpd); + /* + * The Amazon Annapurna Labs 0x0031 device id is reused for other non Root Port + * device types, so the quirk is registered for the PCI_CLASS_BRIDGE_PCI class. diff --git a/queue-5.12/pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch b/queue-5.12/pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch new file mode 100644 index 00000000000..c445355b9ea --- /dev/null +++ b/queue-5.12/pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch @@ -0,0 +1,42 @@ +From 3d0b2a3a87ce5ae85de46c4241afd52ab8b566fe Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Wed, 17 Mar 2021 18:45:18 +0530 +Subject: PCI: keystone: Let AM65 use the pci_ops defined in pcie-designware-host.c +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Kishon Vijay Abraham I + +commit 3d0b2a3a87ce5ae85de46c4241afd52ab8b566fe upstream. + +Both TI's AM65x (K3) and TI's K2 PCIe driver are implemented in +pci-keystone. However Only K2 PCIe driver should use it's own pci_ops +for configuration space accesses. But commit 10a797c6e54a +("PCI: dwc: keystone: Use pci_ops for config space accessors") used +custom pci_ops for both AM65x and K2. This breaks configuration space +access for AM65x platform. Fix it here. + +Link: https://lore.kernel.org/r/20210317131518.11040-1-kishon@ti.com +Fixes: 10a797c6e54a ("PCI: dwc: keystone: Use pci_ops for config space accessors") +Signed-off-by: Kishon Vijay Abraham I +Signed-off-by: Lorenzo Pieralisi +Reviewed-by: Krzysztof Wilczyński +Cc: # v5.10 +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/dwc/pci-keystone.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/controller/dwc/pci-keystone.c ++++ b/drivers/pci/controller/dwc/pci-keystone.c +@@ -798,7 +798,8 @@ static int __init ks_pcie_host_init(stru + int ret; + + pp->bridge->ops = &ks_pcie_ops; +- pp->bridge->child_ops = &ks_child_pcie_ops; ++ if (!ks_pcie->is_am6) ++ pp->bridge->child_ops = &ks_child_pcie_ops; + + ret = ks_pcie_config_legacy_irq(ks_pcie); + if (ret) diff --git a/queue-5.12/pci-xgene-fix-cfg-resource-mapping.patch b/queue-5.12/pci-xgene-fix-cfg-resource-mapping.patch new file mode 100644 index 00000000000..fb4ea954241 --- /dev/null +++ b/queue-5.12/pci-xgene-fix-cfg-resource-mapping.patch @@ -0,0 +1,40 @@ +From d4707d79fae08c8996a1ba45965a491045a22dda Mon Sep 17 00:00:00 2001 +From: Dejin Zheng +Date: Sun, 28 Mar 2021 22:41:18 +0800 +Subject: PCI: xgene: Fix cfg resource mapping + +From: Dejin Zheng + +commit d4707d79fae08c8996a1ba45965a491045a22dda upstream. + +In commit e2dcd20b1645 a change was made to use +devm_platform_ioremap_resource_byname() to simplify code and remove +the res variable; this was wrong since the res variable is still needed +and as an outcome the port->cfg_addr gets an erroneous address. + +Revert the change going back to original behaviour. + +Link: https://lore.kernel.org/r/20210328144118.305074-1-zhengdejin5@gmail.com +Fixes: e2dcd20b1645a ("PCI: controller: Convert to devm_platform_ioremap_resource_byname()") +Reported-by: dann.frazier@canonical.com +Tested-by: dann frazier +Signed-off-by: Dejin Zheng +Signed-off-by: Lorenzo Pieralisi +Cc: stable@vger.kernel.org # v5.9+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/pci/controller/pci-xgene.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/pci/controller/pci-xgene.c ++++ b/drivers/pci/controller/pci-xgene.c +@@ -354,7 +354,8 @@ static int xgene_pcie_map_reg(struct xge + if (IS_ERR(port->csr_base)) + return PTR_ERR(port->csr_base); + +- port->cfg_base = devm_platform_ioremap_resource_byname(pdev, "cfg"); ++ res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "cfg"); ++ port->cfg_base = devm_ioremap_resource(dev, res); + if (IS_ERR(port->cfg_base)) + return PTR_ERR(port->cfg_base); + port->cfg_addr = res->start; diff --git a/queue-5.12/phy-cadence-sierra-fix-phy-power_on-sequence.patch b/queue-5.12/phy-cadence-sierra-fix-phy-power_on-sequence.patch new file mode 100644 index 00000000000..93f6ec0d34d --- /dev/null +++ b/queue-5.12/phy-cadence-sierra-fix-phy-power_on-sequence.patch @@ -0,0 +1,49 @@ +From 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Fri, 19 Mar 2021 18:11:16 +0530 +Subject: phy: cadence: Sierra: Fix PHY power_on sequence + +From: Kishon Vijay Abraham I + +commit 5b4f5757f83be34d1428a1ffbb68d4a1966e9aae upstream. + +Commit 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") +de-asserts PHY_RESET even before the configurations are loaded in +phy_init(). However PHY_RESET should be de-asserted only after +all the configurations has been initialized, instead of de-asserting +in probe. Fix it here. + +Fixes: 44d30d622821d ("phy: cadence: Add driver for Sierra PHY") +Signed-off-by: Kishon Vijay Abraham I +Cc: # v5.4+ +Reviewed-by: Philipp Zabel +Link: https://lore.kernel.org/r/20210319124128.13308-2-kishon@ti.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/phy/cadence/phy-cadence-sierra.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +--- a/drivers/phy/cadence/phy-cadence-sierra.c ++++ b/drivers/phy/cadence/phy-cadence-sierra.c +@@ -319,6 +319,12 @@ static int cdns_sierra_phy_on(struct phy + u32 val; + int ret; + ++ ret = reset_control_deassert(sp->phy_rst); ++ if (ret) { ++ dev_err(dev, "Failed to take the PHY out of reset\n"); ++ return ret; ++ } ++ + /* Take the PHY lane group out of reset */ + ret = reset_control_deassert(ins->lnk_rst); + if (ret) { +@@ -616,7 +622,6 @@ static int cdns_sierra_phy_probe(struct + + pm_runtime_enable(dev); + phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate); +- reset_control_deassert(sp->phy_rst); + return PTR_ERR_OR_ZERO(phy_provider); + + put_child: diff --git a/queue-5.12/phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch b/queue-5.12/phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch new file mode 100644 index 00000000000..02a2d2e9cbb --- /dev/null +++ b/queue-5.12/phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch @@ -0,0 +1,64 @@ +From f7eb147d306ad2efae6837e20d2944f03be42eb4 Mon Sep 17 00:00:00 2001 +From: Kishon Vijay Abraham I +Date: Fri, 19 Mar 2021 18:11:17 +0530 +Subject: phy: ti: j721e-wiz: Invoke wiz_init() before of_platform_device_create() + +From: Kishon Vijay Abraham I + +commit f7eb147d306ad2efae6837e20d2944f03be42eb4 upstream. + +Invoke wiz_init() before configuring anything else in Sierra/Torrent +(invoked as part of of_platform_device_create()). wiz_init() resets the +SERDES device and any configuration done in the probe() of +Sierra/Torrent will be lost. In order to prevent SERDES configuration +from getting reset, invoke wiz_init() immediately before invoking +of_platform_device_create(). + +Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") +Signed-off-by: Kishon Vijay Abraham I +Reviewed-by: Swapnil Jakhade +Cc: # v5.10 +Link: https://lore.kernel.org/r/20210319124128.13308-3-kishon@ti.com +Signed-off-by: Vinod Koul +Signed-off-by: Greg Kroah-Hartman +--- + drivers/phy/ti/phy-j721e-wiz.c | 17 +++++++---------- + 1 file changed, 7 insertions(+), 10 deletions(-) + +--- a/drivers/phy/ti/phy-j721e-wiz.c ++++ b/drivers/phy/ti/phy-j721e-wiz.c +@@ -947,27 +947,24 @@ static int wiz_probe(struct platform_dev + goto err_get_sync; + } + ++ ret = wiz_init(wiz); ++ if (ret) { ++ dev_err(dev, "WIZ initialization failed\n"); ++ goto err_wiz_init; ++ } ++ + serdes_pdev = of_platform_device_create(child_node, NULL, dev); + if (!serdes_pdev) { + dev_WARN(dev, "Unable to create SERDES platform device\n"); + ret = -ENOMEM; +- goto err_pdev_create; +- } +- wiz->serdes_pdev = serdes_pdev; +- +- ret = wiz_init(wiz); +- if (ret) { +- dev_err(dev, "WIZ initialization failed\n"); + goto err_wiz_init; + } ++ wiz->serdes_pdev = serdes_pdev; + + of_node_put(child_node); + return 0; + + err_wiz_init: +- of_platform_device_destroy(&serdes_pdev->dev, NULL); +- +-err_pdev_create: + wiz_clock_cleanup(wiz, node); + + err_get_sync: diff --git a/queue-5.12/pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch b/queue-5.12/pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch new file mode 100644 index 00000000000..9aca2fca3b7 --- /dev/null +++ b/queue-5.12/pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch @@ -0,0 +1,35 @@ +From 8b50a7995770d41a2e8d9c422cd2882aca0dedd2 Mon Sep 17 00:00:00 2001 +From: Lukasz Luba +Date: Mon, 15 Mar 2021 09:31:23 +0000 +Subject: PM / devfreq: Unlock mutex and free devfreq struct in error path + +From: Lukasz Luba + +commit 8b50a7995770d41a2e8d9c422cd2882aca0dedd2 upstream. + +The devfreq->lock is held for time of setup. Release the lock in the +error path, before jumping to the end of the function. + +Change the goto destination which frees the allocated memory. + +Cc: v5.9+ # v5.9+ +Fixes: 4dc3bab8687f ("PM / devfreq: Add support delayed timer for polling mode") +Signed-off-by: Lukasz Luba +Signed-off-by: Chanwoo Choi +Signed-off-by: Greg Kroah-Hartman +--- + drivers/devfreq/devfreq.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/devfreq/devfreq.c ++++ b/drivers/devfreq/devfreq.c +@@ -821,7 +821,8 @@ struct devfreq *devfreq_add_device(struc + + if (devfreq->profile->timer < 0 + || devfreq->profile->timer >= DEVFREQ_TIMER_NUM) { +- goto err_out; ++ mutex_unlock(&devfreq->lock); ++ goto err_dev; + } + + if (!devfreq->profile->max_state && !devfreq->profile->freq_table) { diff --git a/queue-5.12/sc16is7xx-defer-probe-if-device-read-fails.patch b/queue-5.12/sc16is7xx-defer-probe-if-device-read-fails.patch new file mode 100644 index 00000000000..b6a8b19fd18 --- /dev/null +++ b/queue-5.12/sc16is7xx-defer-probe-if-device-read-fails.patch @@ -0,0 +1,41 @@ +From 158e800e0fde91014812f5cdfb92ce812e3a33b4 Mon Sep 17 00:00:00 2001 +From: Annaliese McDermond +Date: Mon, 29 Mar 2021 20:10:49 +0000 +Subject: sc16is7xx: Defer probe if device read fails + +From: Annaliese McDermond + +commit 158e800e0fde91014812f5cdfb92ce812e3a33b4 upstream. + +A test was added to the probe function to ensure the device was +actually connected and working before successfully completing a +probe. If the device was actually there, but the I2C bus was not +ready yet for whatever reason, the probe fails permanently. + +Change the probe so that we defer the probe on a regmap read +failure so that we try the probe again when the dependent drivers +are potentially loaded. This should not affect the case where the +device truly isn't present because the probe will never successfully +complete. + +Fixes: 2aa916e67db3 ("sc16is7xx: Read the LSR register for basic device presence check") +Cc: stable@vger.kernel.org +Signed-off-by: Annaliese McDermond +Link: https://lore.kernel.org/r/010101787f9c3fd8-c1815c00-2d6b-4c85-a96a-a13e68597fda-000000@us-west-2.amazonses.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/sc16is7xx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/tty/serial/sc16is7xx.c ++++ b/drivers/tty/serial/sc16is7xx.c +@@ -1196,7 +1196,7 @@ static int sc16is7xx_probe(struct device + ret = regmap_read(regmap, + SC16IS7XX_LSR_REG << SC16IS7XX_REG_SHIFT, &val); + if (ret < 0) +- return ret; ++ return -EPROBE_DEFER; + + /* Alloc port structure */ + s = devm_kzalloc(dev, struct_size(s, p, devtype->nr_uart), GFP_KERNEL); diff --git a/queue-5.12/selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch b/queue-5.12/selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch new file mode 100644 index 00000000000..638773daeb7 --- /dev/null +++ b/queue-5.12/selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch @@ -0,0 +1,48 @@ +From e4c82eafb609c2badc56f4e11bc50fcf44b8e9eb Mon Sep 17 00:00:00 2001 +From: Paul Moore +Date: Wed, 21 Apr 2021 21:15:36 -0400 +Subject: selinux: add proper NULL termination to the secclass_map permissions + +From: Paul Moore + +commit e4c82eafb609c2badc56f4e11bc50fcf44b8e9eb upstream. + +This patch adds the missing NULL termination to the "bpf" and +"perf_event" object class permission lists. + +This missing NULL termination should really only affect the tools +under scripts/selinux, with the most important being genheaders.c, +although in practice this has not been an issue on any of my dev/test +systems. If the problem were to manifest itself it would likely +result in bogus permissions added to the end of the object class; +thankfully with no access control checks using these bogus +permissions and no policies defining these permissions the impact +would likely be limited to some noise about undefined permissions +during policy load. + +Cc: stable@vger.kernel.org +Fixes: ec27c3568a34 ("selinux: bpf: Add selinux check for eBPF syscall operations") +Fixes: da97e18458fb ("perf_event: Add support for LSM and SELinux checks") +Signed-off-by: Paul Moore +Signed-off-by: Greg Kroah-Hartman +--- + security/selinux/include/classmap.h | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/security/selinux/include/classmap.h ++++ b/security/selinux/include/classmap.h +@@ -242,11 +242,12 @@ struct security_class_mapping secclass_m + { "infiniband_endport", + { "manage_subnet", NULL } }, + { "bpf", +- {"map_create", "map_read", "map_write", "prog_load", "prog_run"} }, ++ { "map_create", "map_read", "map_write", "prog_load", "prog_run", ++ NULL } }, + { "xdp_socket", + { COMMON_SOCK_PERMS, NULL } }, + { "perf_event", +- {"open", "cpu", "kernel", "tracepoint", "read", "write"} }, ++ { "open", "cpu", "kernel", "tracepoint", "read", "write", NULL } }, + { "lockdown", + { "integrity", "confidentiality", NULL } }, + { "anon_inode", diff --git a/queue-5.12/series b/queue-5.12/series index e0459c33cee..2a24d7ff328 100644 --- a/queue-5.12/series +++ b/queue-5.12/series @@ -17,3 +17,40 @@ tty-mxser-fix-tiocsserial-jiffies-conversions.patch staging-fwserial-fix-tiocsserial-permission-check.patch tty-mxser-fix-tiocsserial-permission-check.patch drm-bridge-fix-lontium-use-of-mipi_dsi_-functions.patch +usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch +usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch +usb-typec-tcpm-update-power-supply-once-partner-accepts.patch +usb-serial-xr-fix-csize-handling.patch +usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch +usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch +asoc-samsung-tm2_wm5110-check-of-of_parse-return-value.patch +asoc-intel-kbl_da7219_max98927-fix-kabylake_ssp_fixup-function.patch +asoc-tlv320aic32x4-register-clocks-before-registering-component.patch +asoc-tlv320aic32x4-increase-maximum-register-in-regmap.patch +mips-pci-mt7620-fix-pll-lock-check.patch +mips-pci-rt2880-fix-slot-0-configuration.patch +fddi-defxx-bail-out-gracefully-with-unassigned-pci-resource-for-csr.patch +pci-allow-vpd-access-for-qlogic-isp2722.patch +kvm-x86-defer-the-mmu-unload-to-the-normal-path-on-an-global-invpcid.patch +pci-xgene-fix-cfg-resource-mapping.patch +pci-keystone-let-am65-use-the-pci_ops-defined-in-pcie-designware-host.c.patch +pm-devfreq-unlock-mutex-and-free-devfreq-struct-in-error-path.patch +soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch +iio-inv_mpu6050-fully-validate-gyro-and-accel-scale-writes.patch +iio-magnetometer-yas530-include-right-header.patch +iio-sx9310-fix-write_.._debounce.patch +iio-accel-adis16201-fix-wrong-axis-assignment-that-prevents-loading.patch +iio-adc-ad7476-fix-remove-handling.patch +iio-magnetometer-yas530-fix-return-value-on-error-path.patch +iio-sx9310-fix-access-to-variable-dt-array.patch +iio-hid-sensor-rotation-fix-quaternion-data-not-correct.patch +sc16is7xx-defer-probe-if-device-read-fails.patch +phy-cadence-sierra-fix-phy-power_on-sequence.patch +misc-lis3lv02d-fix-false-positive-warn-on-various-hp-models.patch +phy-ti-j721e-wiz-invoke-wiz_init-before-of_platform_device_create.patch +misc-vmw_vmci-explicitly-initialize-vmci_notify_bm_set_msg-struct.patch +misc-vmw_vmci-explicitly-initialize-vmci_datagram-payload.patch +selinux-add-proper-null-termination-to-the-secclass_map-permissions.patch +x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch +async_xor-increase-src_offs-when-dropping-destination-page.patch +md-bitmap-wait-for-external-bitmap-writes-to-complete-during-tear-down.patch diff --git a/queue-5.12/soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch b/queue-5.12/soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch new file mode 100644 index 00000000000..37a69e98ccf --- /dev/null +++ b/queue-5.12/soc-tegra-regulators-fix-locking-up-when-voltage-spread-is-out-of-range.patch @@ -0,0 +1,38 @@ +From ef85bb582c41524e9e68dfdbde48e519dac4ab3d Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Tue, 2 Mar 2021 16:18:00 +0300 +Subject: soc/tegra: regulators: Fix locking up when voltage-spread is out of range + +From: Dmitry Osipenko + +commit ef85bb582c41524e9e68dfdbde48e519dac4ab3d upstream. + +Fix voltage coupler lockup which happens when voltage-spread is out +of range due to a bug in the code. The max-spread requirement shall be +accounted when CPU regulator doesn't have consumers. This problem is +observed on Tegra30 Ouya game console once system-wide DVFS is enabled +in a device-tree. + +Fixes: 783807436f36 ("soc/tegra: regulators: Add regulators coupler for Tegra30") +Cc: stable@vger.kernel.org +Reported-by: Peter Geis +Tested-by: Peter Geis # Ouya T30 +Tested-by: Matt Merhar # Ouya T30 +Signed-off-by: Dmitry Osipenko +Signed-off-by: Thierry Reding +Signed-off-by: Greg Kroah-Hartman +--- + drivers/soc/tegra/regulators-tegra30.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/soc/tegra/regulators-tegra30.c ++++ b/drivers/soc/tegra/regulators-tegra30.c +@@ -178,7 +178,7 @@ static int tegra30_voltage_update(struct + * survive the voltage drop if it's running on a higher frequency. + */ + if (!cpu_min_uV_consumers) +- cpu_min_uV = cpu_uV; ++ cpu_min_uV = max(cpu_uV, cpu_min_uV); + + /* + * Bootloader shall set up voltages correctly, but if it diff --git a/queue-5.12/usb-serial-xr-fix-csize-handling.patch b/queue-5.12/usb-serial-xr-fix-csize-handling.patch new file mode 100644 index 00000000000..03560b888c4 --- /dev/null +++ b/queue-5.12/usb-serial-xr-fix-csize-handling.patch @@ -0,0 +1,37 @@ +From ea7ada4de2f7406150dd35ecd0302842587a464e Mon Sep 17 00:00:00 2001 +From: Johan Hovold +Date: Tue, 30 Mar 2021 16:37:16 +0200 +Subject: USB: serial: xr: fix CSIZE handling + +From: Johan Hovold + +commit ea7ada4de2f7406150dd35ecd0302842587a464e upstream. + +The XR21V141X does not have a 5- or 6-bit mode, but the current +implementation failed to properly restore the old setting when CS5 or +CS6 was requested. Instead an invalid request would be sent to the +device. + +Fixes: c2d405aa86b4 ("USB: serial: add MaxLinear/Exar USB to Serial driver") +Reviewed-by: Manivannan Sadhasivam +Cc: stable@vger.kernel.org # 5.12 +Signed-off-by: Johan Hovold +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/serial/xr_serial.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/usb/serial/xr_serial.c ++++ b/drivers/usb/serial/xr_serial.c +@@ -468,6 +468,11 @@ static void xr_set_termios(struct tty_st + if (old_termios) + termios->c_cflag |= old_termios->c_cflag & CSIZE; + else ++ termios->c_cflag |= CS8; ++ ++ if (C_CSIZE(tty) == CS7) ++ bits |= XR21V141X_UART_DATA_7; ++ else + bits |= XR21V141X_UART_DATA_8; + break; + case CS7: diff --git a/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch b/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch new file mode 100644 index 00000000000..f33944c9be4 --- /dev/null +++ b/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-fixed-supply.patch @@ -0,0 +1,76 @@ +From f3dedafb8263ca4791a92a23f5230068f5bde008 Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:18 -0700 +Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for fixed supply + +From: Badhri Jagan Sridharan + +commit f3dedafb8263ca4791a92a23f5230068f5bde008 upstream. + +tcpm_pd_build_request overwrites current_limit and supply_voltage +even before port partner accepts the requests. This leaves stale +values in current_limit and supply_voltage that get exported by +"tcpm-source-psy-". Solving this problem by caching the request +values of current limit/supply voltage in req_current_limit +and req_supply_voltage. current_limit/supply_voltage gets updated +once the port partner accepts the request. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Guenter Roeck +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-1-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -389,7 +389,10 @@ struct tcpm_port { + unsigned int operating_snk_mw; + bool update_sink_caps; + +- /* Requested current / voltage */ ++ /* Requested current / voltage to the port partner */ ++ u32 req_current_limit; ++ u32 req_supply_voltage; ++ /* Actual current / voltage limit of the local port */ + u32 current_limit; + u32 supply_voltage; + +@@ -2432,8 +2435,8 @@ static void tcpm_pd_ctrl_request(struct + case SNK_TRANSITION_SINK: + if (port->vbus_present) { + tcpm_set_current_limit(port, +- port->current_limit, +- port->supply_voltage); ++ port->req_current_limit, ++ port->req_supply_voltage); + port->explicit_contract = true; + tcpm_set_auto_vbus_discharge_threshold(port, + TYPEC_PWR_MODE_PD, +@@ -2542,8 +2545,8 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + port->pps_data.active = true; +- port->supply_voltage = port->pps_data.out_volt; +- port->current_limit = port->pps_data.op_curr; ++ port->req_supply_voltage = port->pps_data.out_volt; ++ port->req_current_limit = port->pps_data.op_curr; + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -3192,8 +3195,8 @@ static int tcpm_pd_build_request(struct + flags & RDO_CAP_MISMATCH ? " [mismatch]" : ""); + } + +- port->current_limit = ma; +- port->supply_voltage = mv; ++ port->req_current_limit = ma; ++ port->req_supply_voltage = mv; + + return 0; + } diff --git a/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch b/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch new file mode 100644 index 00000000000..bdb28d9c55f --- /dev/null +++ b/queue-5.12/usb-typec-tcpm-address-incorrect-values-of-tcpm-psy-for-pps-supply.patch @@ -0,0 +1,228 @@ +From e3a0720224873587954b55d193d5b4abb14f0443 Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:19 -0700 +Subject: usb: typec: tcpm: Address incorrect values of tcpm psy for pps supply + +From: Badhri Jagan Sridharan + +commit e3a0720224873587954b55d193d5b4abb14f0443 upstream. + +tcpm_pd_select_pps_apdo overwrites port->pps_data.min_volt, +port->pps_data.max_volt, port->pps_data.max_curr even before +port partner accepts the requests. This leaves incorrect values +in current_limit and supply_voltage that get exported by +"tcpm-source-psy-". Solving this problem by caching the request +values in req_min_volt, req_max_volt, req_max_curr, req_out_volt, +req_op_curr. min_volt, max_volt, max_curr gets updated once the +partner accepts the request. current_limit, supply_voltage gets updated +once local port's tcpm enters SNK_TRANSITION_SINK when the accepted +current_limit and supply_voltage is enforced. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-2-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 88 +++++++++++++++++++++++++----------------- + 1 file changed, 53 insertions(+), 35 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -268,12 +268,27 @@ struct pd_mode_data { + struct typec_altmode_desc altmode_desc[ALTMODE_DISCOVERY_MAX]; + }; + ++/* ++ * @min_volt: Actual min voltage at the local port ++ * @req_min_volt: Requested min voltage to the port partner ++ * @max_volt: Actual max voltage at the local port ++ * @req_max_volt: Requested max voltage to the port partner ++ * @max_curr: Actual max current at the local port ++ * @req_max_curr: Requested max current of the port partner ++ * @req_out_volt: Requested output voltage to the port partner ++ * @req_op_curr: Requested operating current to the port partner ++ * @supported: Parter has atleast one APDO hence supports PPS ++ * @active: PPS mode is active ++ */ + struct pd_pps_data { + u32 min_volt; ++ u32 req_min_volt; + u32 max_volt; ++ u32 req_max_volt; + u32 max_curr; +- u32 out_volt; +- u32 op_curr; ++ u32 req_max_curr; ++ u32 req_out_volt; ++ u32 req_op_curr; + bool supported; + bool active; + }; +@@ -2495,8 +2510,8 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + /* Revert data back from any requested PPS updates */ +- port->pps_data.out_volt = port->supply_voltage; +- port->pps_data.op_curr = port->current_limit; ++ port->pps_data.req_out_volt = port->supply_voltage; ++ port->pps_data.req_op_curr = port->current_limit; + port->pps_status = (type == PD_CTRL_WAIT ? + -EAGAIN : -EOPNOTSUPP); + +@@ -2545,8 +2560,11 @@ static void tcpm_pd_ctrl_request(struct + break; + case SNK_NEGOTIATE_PPS_CAPABILITIES: + port->pps_data.active = true; +- port->req_supply_voltage = port->pps_data.out_volt; +- port->req_current_limit = port->pps_data.op_curr; ++ port->pps_data.min_volt = port->pps_data.req_min_volt; ++ port->pps_data.max_volt = port->pps_data.req_max_volt; ++ port->pps_data.max_curr = port->pps_data.req_max_curr; ++ port->req_supply_voltage = port->pps_data.req_out_volt; ++ port->req_current_limit = port->pps_data.req_op_curr; + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -3105,16 +3123,16 @@ static unsigned int tcpm_pd_select_pps_a + src = port->source_caps[src_pdo]; + snk = port->snk_pdo[snk_pdo]; + +- port->pps_data.min_volt = max(pdo_pps_apdo_min_voltage(src), +- pdo_pps_apdo_min_voltage(snk)); +- port->pps_data.max_volt = min(pdo_pps_apdo_max_voltage(src), +- pdo_pps_apdo_max_voltage(snk)); +- port->pps_data.max_curr = min_pps_apdo_current(src, snk); +- port->pps_data.out_volt = min(port->pps_data.max_volt, +- max(port->pps_data.min_volt, +- port->pps_data.out_volt)); +- port->pps_data.op_curr = min(port->pps_data.max_curr, +- port->pps_data.op_curr); ++ port->pps_data.req_min_volt = max(pdo_pps_apdo_min_voltage(src), ++ pdo_pps_apdo_min_voltage(snk)); ++ port->pps_data.req_max_volt = min(pdo_pps_apdo_max_voltage(src), ++ pdo_pps_apdo_max_voltage(snk)); ++ port->pps_data.req_max_curr = min_pps_apdo_current(src, snk); ++ port->pps_data.req_out_volt = min(port->pps_data.max_volt, ++ max(port->pps_data.min_volt, ++ port->pps_data.req_out_volt)); ++ port->pps_data.req_op_curr = min(port->pps_data.max_curr, ++ port->pps_data.req_op_curr); + power_supply_changed(port->psy); + } + +@@ -3242,10 +3260,10 @@ static int tcpm_pd_build_pps_request(str + tcpm_log(port, "Invalid APDO selected!"); + return -EINVAL; + } +- max_mv = port->pps_data.max_volt; +- max_ma = port->pps_data.max_curr; +- out_mv = port->pps_data.out_volt; +- op_ma = port->pps_data.op_curr; ++ max_mv = port->pps_data.req_max_volt; ++ max_ma = port->pps_data.req_max_curr; ++ out_mv = port->pps_data.req_out_volt; ++ op_ma = port->pps_data.req_op_curr; + break; + default: + tcpm_log(port, "Invalid PDO selected!"); +@@ -3292,8 +3310,8 @@ static int tcpm_pd_build_pps_request(str + tcpm_log(port, "Requesting APDO %d: %u mV, %u mA", + src_pdo_index, out_mv, op_ma); + +- port->pps_data.op_curr = op_ma; +- port->pps_data.out_volt = out_mv; ++ port->pps_data.req_op_curr = op_ma; ++ port->pps_data.req_out_volt = out_mv; + + return 0; + } +@@ -5377,7 +5395,7 @@ static int tcpm_try_role(struct typec_po + return ret; + } + +-static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 op_curr) ++static int tcpm_pps_set_op_curr(struct tcpm_port *port, u16 req_op_curr) + { + unsigned int target_mw; + int ret; +@@ -5395,12 +5413,12 @@ static int tcpm_pps_set_op_curr(struct t + goto port_unlock; + } + +- if (op_curr > port->pps_data.max_curr) { ++ if (req_op_curr > port->pps_data.max_curr) { + ret = -EINVAL; + goto port_unlock; + } + +- target_mw = (op_curr * port->pps_data.out_volt) / 1000; ++ target_mw = (req_op_curr * port->supply_voltage) / 1000; + if (target_mw < port->operating_snk_mw) { + ret = -EINVAL; + goto port_unlock; +@@ -5414,10 +5432,10 @@ static int tcpm_pps_set_op_curr(struct t + } + + /* Round down operating current to align with PPS valid steps */ +- op_curr = op_curr - (op_curr % RDO_PROG_CURR_MA_STEP); ++ req_op_curr = req_op_curr - (req_op_curr % RDO_PROG_CURR_MA_STEP); + + reinit_completion(&port->pps_complete); +- port->pps_data.op_curr = op_curr; ++ port->pps_data.req_op_curr = req_op_curr; + port->pps_status = 0; + port->pps_pending = true; + mutex_unlock(&port->lock); +@@ -5438,7 +5456,7 @@ swap_unlock: + return ret; + } + +-static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 out_volt) ++static int tcpm_pps_set_out_volt(struct tcpm_port *port, u16 req_out_volt) + { + unsigned int target_mw; + int ret; +@@ -5456,13 +5474,13 @@ static int tcpm_pps_set_out_volt(struct + goto port_unlock; + } + +- if (out_volt < port->pps_data.min_volt || +- out_volt > port->pps_data.max_volt) { ++ if (req_out_volt < port->pps_data.min_volt || ++ req_out_volt > port->pps_data.max_volt) { + ret = -EINVAL; + goto port_unlock; + } + +- target_mw = (port->pps_data.op_curr * out_volt) / 1000; ++ target_mw = (port->current_limit * req_out_volt) / 1000; + if (target_mw < port->operating_snk_mw) { + ret = -EINVAL; + goto port_unlock; +@@ -5476,10 +5494,10 @@ static int tcpm_pps_set_out_volt(struct + } + + /* Round down output voltage to align with PPS valid steps */ +- out_volt = out_volt - (out_volt % RDO_PROG_VOLT_MV_STEP); ++ req_out_volt = req_out_volt - (req_out_volt % RDO_PROG_VOLT_MV_STEP); + + reinit_completion(&port->pps_complete); +- port->pps_data.out_volt = out_volt; ++ port->pps_data.req_out_volt = req_out_volt; + port->pps_status = 0; + port->pps_pending = true; + mutex_unlock(&port->lock); +@@ -5537,8 +5555,8 @@ static int tcpm_pps_activate(struct tcpm + + /* Trigger PPS request or move back to standard PDO contract */ + if (activate) { +- port->pps_data.out_volt = port->supply_voltage; +- port->pps_data.op_curr = port->current_limit; ++ port->pps_data.req_out_volt = port->supply_voltage; ++ port->pps_data.req_op_curr = port->current_limit; + } + mutex_unlock(&port->lock); + diff --git a/queue-5.12/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch b/queue-5.12/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch new file mode 100644 index 00000000000..4e5d7966daa --- /dev/null +++ b/queue-5.12/usb-typec-tcpm-update-power-supply-once-partner-accepts.patch @@ -0,0 +1,55 @@ +From 4050f2683f2c3151dc3dd1501ac88c57caf810ff Mon Sep 17 00:00:00 2001 +From: Badhri Jagan Sridharan +Date: Wed, 7 Apr 2021 13:07:20 -0700 +Subject: usb: typec: tcpm: update power supply once partner accepts + +From: Badhri Jagan Sridharan + +commit 4050f2683f2c3151dc3dd1501ac88c57caf810ff upstream. + +power_supply_changed needs to be called to notify clients +after the partner accepts the requested values for the pps +case. + +Also, remove the redundant power_supply_changed at the end +of the tcpm_reset_port as power_supply_changed is already +called right after usb_type is changed. + +Fixes: f2a8aa053c176 ("typec: tcpm: Represent source supply through power_supply") +Signed-off-by: Badhri Jagan Sridharan +Cc: stable +Reviewed-by: Adam Thomson +Reviewed-by: Heikki Krogerus +Link: https://lore.kernel.org/r/20210407200723.1914388-3-badhri@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/typec/tcpm/tcpm.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/usb/typec/tcpm/tcpm.c ++++ b/drivers/usb/typec/tcpm/tcpm.c +@@ -2565,6 +2565,7 @@ static void tcpm_pd_ctrl_request(struct + port->pps_data.max_curr = port->pps_data.req_max_curr; + port->req_supply_voltage = port->pps_data.req_out_volt; + port->req_current_limit = port->pps_data.req_op_curr; ++ power_supply_changed(port->psy); + tcpm_set_state(port, SNK_TRANSITION_SINK, 0); + break; + case SOFT_RESET_SEND: +@@ -3133,7 +3134,6 @@ static unsigned int tcpm_pd_select_pps_a + port->pps_data.req_out_volt)); + port->pps_data.req_op_curr = min(port->pps_data.max_curr, + port->pps_data.req_op_curr); +- power_supply_changed(port->psy); + } + + return src_pdo; +@@ -3554,8 +3554,6 @@ static void tcpm_reset_port(struct tcpm_ + port->sink_cap_done = false; + if (port->tcpc->enable_frs) + port->tcpc->enable_frs(port->tcpc, false); +- +- power_supply_changed(port->psy); + } + + static void tcpm_detach(struct tcpm_port *port) diff --git a/queue-5.12/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch b/queue-5.12/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch new file mode 100644 index 00000000000..bfee4840573 --- /dev/null +++ b/queue-5.12/usb-xhci-mtk-improve-bandwidth-scheduling-with-tt.patch @@ -0,0 +1,178 @@ +From e19ee44a3d07c232f9241024dab1ebd0748cdf5f Mon Sep 17 00:00:00 2001 +From: Chunfeng Yun +Date: Mon, 8 Mar 2021 10:51:51 +0800 +Subject: usb: xhci-mtk: improve bandwidth scheduling with TT + +From: Chunfeng Yun + +commit e19ee44a3d07c232f9241024dab1ebd0748cdf5f upstream. + +When the USB headset is plug into an external hub, sometimes +can't set config due to not enough bandwidth, so need improve +LS/FS INT/ISOC bandwidth scheduling with TT. + +Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") +Cc: stable +Signed-off-by: Yaqii Wu +Signed-off-by: Chunfeng Yun +Link: https://lore.kernel.org/r/2f30e81400a59afef5f8231c98149169c7520519.1615170625.git.chunfeng.yun@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mtk-sch.c | 74 ++++++++++++++++++++++++++++++++-------- + drivers/usb/host/xhci-mtk.h | 6 ++- + 2 files changed, 64 insertions(+), 16 deletions(-) + +--- a/drivers/usb/host/xhci-mtk-sch.c ++++ b/drivers/usb/host/xhci-mtk-sch.c +@@ -378,6 +378,31 @@ static void update_bus_bw(struct mu3h_sc + sch_ep->allocated = used; + } + ++static int check_fs_bus_bw(struct mu3h_sch_ep_info *sch_ep, int offset) ++{ ++ struct mu3h_sch_tt *tt = sch_ep->sch_tt; ++ u32 num_esit, tmp; ++ int base; ++ int i, j; ++ ++ num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; ++ for (i = 0; i < num_esit; i++) { ++ base = offset + i * sch_ep->esit; ++ ++ /* ++ * Compared with hs bus, no matter what ep type, ++ * the hub will always delay one uframe to send data ++ */ ++ for (j = 0; j < sch_ep->cs_count; j++) { ++ tmp = tt->fs_bus_bw[base + j] + sch_ep->bw_cost_per_microframe; ++ if (tmp > FS_PAYLOAD_MAX) ++ return -ERANGE; ++ } ++ } ++ ++ return 0; ++} ++ + static int check_sch_tt(struct usb_device *udev, + struct mu3h_sch_ep_info *sch_ep, u32 offset) + { +@@ -402,7 +427,7 @@ static int check_sch_tt(struct usb_devic + return -ERANGE; + + for (i = 0; i < sch_ep->cs_count; i++) +- if (test_bit(offset + i, tt->split_bit_map)) ++ if (test_bit(offset + i, tt->ss_bit_map)) + return -ERANGE; + + } else { +@@ -432,7 +457,7 @@ static int check_sch_tt(struct usb_devic + cs_count = 7; /* HW limit */ + + for (i = 0; i < cs_count + 2; i++) { +- if (test_bit(offset + i, tt->split_bit_map)) ++ if (test_bit(offset + i, tt->ss_bit_map)) + return -ERANGE; + } + +@@ -448,24 +473,44 @@ static int check_sch_tt(struct usb_devic + sch_ep->num_budget_microframes = sch_ep->esit; + } + +- return 0; ++ return check_fs_bus_bw(sch_ep, offset); + } + + static void update_sch_tt(struct usb_device *udev, +- struct mu3h_sch_ep_info *sch_ep) ++ struct mu3h_sch_ep_info *sch_ep, bool used) + { + struct mu3h_sch_tt *tt = sch_ep->sch_tt; + u32 base, num_esit; ++ int bw_updated; ++ int bits; + int i, j; + + num_esit = XHCI_MTK_MAX_ESIT / sch_ep->esit; ++ bits = (sch_ep->ep_type == ISOC_OUT_EP) ? sch_ep->cs_count : 1; ++ ++ if (used) ++ bw_updated = sch_ep->bw_cost_per_microframe; ++ else ++ bw_updated = -sch_ep->bw_cost_per_microframe; ++ + for (i = 0; i < num_esit; i++) { + base = sch_ep->offset + i * sch_ep->esit; +- for (j = 0; j < sch_ep->num_budget_microframes; j++) +- set_bit(base + j, tt->split_bit_map); ++ ++ for (j = 0; j < bits; j++) { ++ if (used) ++ set_bit(base + j, tt->ss_bit_map); ++ else ++ clear_bit(base + j, tt->ss_bit_map); ++ } ++ ++ for (j = 0; j < sch_ep->cs_count; j++) ++ tt->fs_bus_bw[base + j] += bw_updated; + } + +- list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list); ++ if (used) ++ list_add_tail(&sch_ep->tt_endpoint, &tt->ep_list); ++ else ++ list_del(&sch_ep->tt_endpoint); + } + + static int check_sch_bw(struct usb_device *udev, +@@ -535,7 +580,7 @@ static int check_sch_bw(struct usb_devic + if (!tt_offset_ok) + return -ERANGE; + +- update_sch_tt(udev, sch_ep); ++ update_sch_tt(udev, sch_ep, 1); + } + + /* update bus bandwidth info */ +@@ -548,15 +593,16 @@ static void destroy_sch_ep(struct usb_de + struct mu3h_sch_bw_info *sch_bw, struct mu3h_sch_ep_info *sch_ep) + { + /* only release ep bw check passed by check_sch_bw() */ +- if (sch_ep->allocated) ++ if (sch_ep->allocated) { + update_bus_bw(sch_bw, sch_ep, 0); ++ if (sch_ep->sch_tt) ++ update_sch_tt(udev, sch_ep, 0); ++ } + +- list_del(&sch_ep->endpoint); +- +- if (sch_ep->sch_tt) { +- list_del(&sch_ep->tt_endpoint); ++ if (sch_ep->sch_tt) + drop_tt(udev); +- } ++ ++ list_del(&sch_ep->endpoint); + kfree(sch_ep); + } + +--- a/drivers/usb/host/xhci-mtk.h ++++ b/drivers/usb/host/xhci-mtk.h +@@ -20,13 +20,15 @@ + #define XHCI_MTK_MAX_ESIT 64 + + /** +- * @split_bit_map: used to avoid split microframes overlay ++ * @ss_bit_map: used to avoid start split microframes overlay ++ * @fs_bus_bw: array to keep track of bandwidth already used for FS + * @ep_list: Endpoints using this TT + * @usb_tt: usb TT related + * @tt_port: TT port number + */ + struct mu3h_sch_tt { +- DECLARE_BITMAP(split_bit_map, XHCI_MTK_MAX_ESIT); ++ DECLARE_BITMAP(ss_bit_map, XHCI_MTK_MAX_ESIT); ++ u32 fs_bus_bw[XHCI_MTK_MAX_ESIT]; + struct list_head ep_list; + struct usb_tt *usb_tt; + int tt_port; diff --git a/queue-5.12/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch b/queue-5.12/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch new file mode 100644 index 00000000000..9685681db02 --- /dev/null +++ b/queue-5.12/usb-xhci-mtk-remove-or-operator-for-setting-schedule-parameters.patch @@ -0,0 +1,46 @@ +From 5fa5827566e3affa1657ccf9b22706c06a5d021a Mon Sep 17 00:00:00 2001 +From: Chunfeng Yun +Date: Mon, 8 Mar 2021 10:51:50 +0800 +Subject: usb: xhci-mtk: remove or operator for setting schedule parameters + +From: Chunfeng Yun + +commit 5fa5827566e3affa1657ccf9b22706c06a5d021a upstream. + +Side effect may happen if use or operator to set schedule parameters +when the parameters are already set before. Set them directly due to +other bits are reserved. + +Fixes: 54f6a8af3722 ("usb: xhci-mtk: skip dropping bandwidth of unchecked endpoints") +Cc: stable +Signed-off-by: Chunfeng Yun +Link: https://lore.kernel.org/r/d287899e6beb2fc1bfb8900c75a872f628ecde55.1615170625.git.chunfeng.yun@mediatek.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/host/xhci-mtk-sch.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/usb/host/xhci-mtk-sch.c ++++ b/drivers/usb/host/xhci-mtk-sch.c +@@ -643,7 +643,7 @@ int xhci_mtk_add_ep_quirk(struct usb_hcd + */ + if (usb_endpoint_xfer_int(&ep->desc) + || usb_endpoint_xfer_isoc(&ep->desc)) +- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(1)); ++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(1)); + + return 0; + } +@@ -730,10 +730,10 @@ int xhci_mtk_check_bandwidth(struct usb_ + list_move_tail(&sch_ep->endpoint, &sch_bw->bw_ep_list); + + ep_ctx = xhci_get_ep_ctx(xhci, virt_dev->in_ctx, ep_index); +- ep_ctx->reserved[0] |= cpu_to_le32(EP_BPKTS(sch_ep->pkts) ++ ep_ctx->reserved[0] = cpu_to_le32(EP_BPKTS(sch_ep->pkts) + | EP_BCSCOUNT(sch_ep->cs_count) + | EP_BBM(sch_ep->burst_mode)); +- ep_ctx->reserved[1] |= cpu_to_le32(EP_BOFFSET(sch_ep->offset) ++ ep_ctx->reserved[1] = cpu_to_le32(EP_BOFFSET(sch_ep->offset) + | EP_BREPEAT(sch_ep->repeat)); + + xhci_dbg(xhci, " PKTS:%x, CSCOUNT:%x, BM:%x, OFFSET:%x, REPEAT:%x\n", diff --git a/queue-5.12/x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch b/queue-5.12/x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch new file mode 100644 index 00000000000..154df189843 --- /dev/null +++ b/queue-5.12/x86-sched-treat-intel-snc-topology-as-default-cod-as-exception.patch @@ -0,0 +1,189 @@ +From 2c88d45edbb89029c1190bb3b136d2602f057c98 Mon Sep 17 00:00:00 2001 +From: Alison Schofield +Date: Wed, 10 Mar 2021 11:02:33 -0800 +Subject: x86, sched: Treat Intel SNC topology as default, COD as exception + +From: Alison Schofield + +commit 2c88d45edbb89029c1190bb3b136d2602f057c98 upstream. + +Commit 1340ccfa9a9a ("x86,sched: Allow topologies where NUMA nodes +share an LLC") added a vendor and model specific check to never +call topology_sane() for Intel Skylake Server systems where NUMA +nodes share an LLC. + +Intel Ice Lake and Sapphire Rapids CPUs also enumerate an LLC that is +shared by multiple NUMA nodes. The LLC on these CPUs is shared for +off-package data access but private to the NUMA node for on-package +access. Rather than managing a list of allowable SNC topologies, make +this SNC topology the default, and treat Intel's Cluster-On-Die (COD) +topology as the exception. + +In SNC mode, Sky Lake, Ice Lake, and Sapphire Rapids servers do not +emit this warning: + +sched: CPU #3's llc-sibling CPU #0 is not on the same node! [node: 1 != 0]. Ignoring dependency. + +Suggested-by: Peter Zijlstra (Intel) +Signed-off-by: Alison Schofield +Signed-off-by: Peter Zijlstra (Intel) +Acked-by: Dave Hansen +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20210310190233.31752-1-alison.schofield@intel.com +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/smpboot.c | 90 +++++++++++++++++++++++----------------------- + 1 file changed, 46 insertions(+), 44 deletions(-) + +--- a/arch/x86/kernel/smpboot.c ++++ b/arch/x86/kernel/smpboot.c +@@ -458,29 +458,52 @@ static bool match_smt(struct cpuinfo_x86 + return false; + } + ++static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) ++{ ++ if (c->phys_proc_id == o->phys_proc_id && ++ c->cpu_die_id == o->cpu_die_id) ++ return true; ++ return false; ++} ++ + /* +- * Define snc_cpu[] for SNC (Sub-NUMA Cluster) CPUs. ++ * Unlike the other levels, we do not enforce keeping a ++ * multicore group inside a NUMA node. If this happens, we will ++ * discard the MC level of the topology later. ++ */ ++static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) ++{ ++ if (c->phys_proc_id == o->phys_proc_id) ++ return true; ++ return false; ++} ++ ++/* ++ * Define intel_cod_cpu[] for Intel COD (Cluster-on-Die) CPUs. + * +- * These are Intel CPUs that enumerate an LLC that is shared by +- * multiple NUMA nodes. The LLC on these systems is shared for +- * off-package data access but private to the NUMA node (half +- * of the package) for on-package access. ++ * Any Intel CPU that has multiple nodes per package and does not ++ * match intel_cod_cpu[] has the SNC (Sub-NUMA Cluster) topology. + * +- * CPUID (the source of the information about the LLC) can only +- * enumerate the cache as being shared *or* unshared, but not +- * this particular configuration. The CPU in this case enumerates +- * the cache to be shared across the entire package (spanning both +- * NUMA nodes). ++ * When in SNC mode, these CPUs enumerate an LLC that is shared ++ * by multiple NUMA nodes. The LLC is shared for off-package data ++ * access but private to the NUMA node (half of the package) for ++ * on-package access. CPUID (the source of the information about ++ * the LLC) can only enumerate the cache as shared or unshared, ++ * but not this particular configuration. + */ + +-static const struct x86_cpu_id snc_cpu[] = { +- X86_MATCH_INTEL_FAM6_MODEL(SKYLAKE_X, NULL), ++static const struct x86_cpu_id intel_cod_cpu[] = { ++ X86_MATCH_INTEL_FAM6_MODEL(HASWELL_X, 0), /* COD */ ++ X86_MATCH_INTEL_FAM6_MODEL(BROADWELL_X, 0), /* COD */ ++ X86_MATCH_INTEL_FAM6_MODEL(ANY, 1), /* SNC */ + {} + }; + + static bool match_llc(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) + { ++ const struct x86_cpu_id *id = x86_match_cpu(intel_cod_cpu); + int cpu1 = c->cpu_index, cpu2 = o->cpu_index; ++ bool intel_snc = id && id->driver_data; + + /* Do not match if we do not have a valid APICID for cpu: */ + if (per_cpu(cpu_llc_id, cpu1) == BAD_APICID) +@@ -495,32 +518,12 @@ static bool match_llc(struct cpuinfo_x86 + * means 'c' does not share the LLC of 'o'. This will be + * reflected to userspace. + */ +- if (!topology_same_node(c, o) && x86_match_cpu(snc_cpu)) ++ if (match_pkg(c, o) && !topology_same_node(c, o) && intel_snc) + return false; + + return topology_sane(c, o, "llc"); + } + +-/* +- * Unlike the other levels, we do not enforce keeping a +- * multicore group inside a NUMA node. If this happens, we will +- * discard the MC level of the topology later. +- */ +-static bool match_pkg(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) +-{ +- if (c->phys_proc_id == o->phys_proc_id) +- return true; +- return false; +-} +- +-static bool match_die(struct cpuinfo_x86 *c, struct cpuinfo_x86 *o) +-{ +- if ((c->phys_proc_id == o->phys_proc_id) && +- (c->cpu_die_id == o->cpu_die_id)) +- return true; +- return false; +-} +- + + #if defined(CONFIG_SCHED_SMT) || defined(CONFIG_SCHED_MC) + static inline int x86_sched_itmt_flags(void) +@@ -592,14 +595,23 @@ void set_cpu_sibling_map(int cpu) + for_each_cpu(i, cpu_sibling_setup_mask) { + o = &cpu_data(i); + ++ if (match_pkg(c, o) && !topology_same_node(c, o)) ++ x86_has_numa_in_package = true; ++ + if ((i == cpu) || (has_smt && match_smt(c, o))) + link_mask(topology_sibling_cpumask, cpu, i); + + if ((i == cpu) || (has_mp && match_llc(c, o))) + link_mask(cpu_llc_shared_mask, cpu, i); + ++ if ((i == cpu) || (has_mp && match_die(c, o))) ++ link_mask(topology_die_cpumask, cpu, i); + } + ++ threads = cpumask_weight(topology_sibling_cpumask(cpu)); ++ if (threads > __max_smt_threads) ++ __max_smt_threads = threads; ++ + /* + * This needs a separate iteration over the cpus because we rely on all + * topology_sibling_cpumask links to be set-up. +@@ -613,8 +625,7 @@ void set_cpu_sibling_map(int cpu) + /* + * Does this new cpu bringup a new core? + */ +- if (cpumask_weight( +- topology_sibling_cpumask(cpu)) == 1) { ++ if (threads == 1) { + /* + * for each core in package, increment + * the booted_cores for this new cpu +@@ -631,16 +642,7 @@ void set_cpu_sibling_map(int cpu) + } else if (i != cpu && !c->booted_cores) + c->booted_cores = cpu_data(i).booted_cores; + } +- if (match_pkg(c, o) && !topology_same_node(c, o)) +- x86_has_numa_in_package = true; +- +- if ((i == cpu) || (has_mp && match_die(c, o))) +- link_mask(topology_die_cpumask, cpu, i); + } +- +- threads = cpumask_weight(topology_sibling_cpumask(cpu)); +- if (threads > __max_smt_threads) +- __max_smt_threads = threads; + } + + /* maps the cpu to the sched domain representing multi-core */