From: hackyzh002 hackyzh002@gmail.com
[ Upstream commit f828b681d0cd566f86351c0b913e6cb6ed8c7b9c ]
The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later
Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: hackyzh002 hackyzh002@gmail.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/radeon/radeon_cs.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index a78b60b62caf2..87a57e5588a28 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++ b/drivers/gpu/drm/radeon/radeon_cs.c @@ -271,7 +271,8 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void *data) { struct drm_radeon_cs *cs = data; uint64_t *chunk_array_ptr; - unsigned size, i; + u64 size; + unsigned i; u32 ring = RADEON_CS_RING_GFX; s32 priority = 0;
From: Oswald Buddenhagen oswald.buddenhagen@gmx.de
[ Upstream commit 8cabf83c7aa54530e699be56249fb44f9505c4f3 ]
There is no apparent reason for the massive code duplication.
Signed-off-by: Oswald Buddenhagen oswald.buddenhagen@gmx.de Link: https://lore.kernel.org/r/20230510173917.3073107-3-oswald.buddenhagen@gmx.de Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org --- sound/pci/emu10k1/emufx.c | 112 +++----------------------------------- 1 file changed, 9 insertions(+), 103 deletions(-)
diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c index 4e76ed0e91d5d..e17b93b25d2ff 100644 --- a/sound/pci/emu10k1/emufx.c +++ b/sound/pci/emu10k1/emufx.c @@ -1560,14 +1560,8 @@ A_OP(icode, &ptr, iMAC0, A_GPR(var), A_GPR(var), A_GPR(vol), A_EXTIN(input)) gpr += 2;
/* Master volume (will be renamed later) */ - A_OP(icode, &ptr, iMAC0, A_GPR(playback+0+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+0+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+1+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+1+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+2+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+2+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+3+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+3+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+4+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+4+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+5+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+5+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+6+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+6+SND_EMU10K1_PLAYBACK_CHANNELS)); - A_OP(icode, &ptr, iMAC0, A_GPR(playback+7+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+7+SND_EMU10K1_PLAYBACK_CHANNELS)); + for (z = 0; z < 8; z++) + A_OP(icode, &ptr, iMAC0, A_GPR(playback+z+SND_EMU10K1_PLAYBACK_CHANNELS), A_C_00000000, A_GPR(gpr), A_GPR(playback+z+SND_EMU10K1_PLAYBACK_CHANNELS)); snd_emu10k1_init_mono_control(&controls[nctl++], "Wave Master Playback Volume", gpr, 0); gpr += 2;
@@ -1651,102 +1645,14 @@ A_OP(icode, &ptr, iMAC0, A_GPR(var), A_GPR(var), A_GPR(vol), A_EXTIN(input)) dev_dbg(emu->card->dev, "emufx.c: gpr=0x%x, tmp=0x%x\n", gpr, tmp); */ - /* For the EMU1010: How to get 32bit values from the DSP. High 16bits into L, low 16bits into R. */ - /* A_P16VIN(0) is delayed by one sample, - * so all other A_P16VIN channels will need to also be delayed - */ - /* Left ADC in. 1 of 2 */ snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_P16VIN(0x0), A_FXBUS2(0) ); - /* Right ADC in 1 of 2 */ - gpr_map[gpr++] = 0x00000000; - /* Delaying by one sample: instead of copying the input - * value A_P16VIN to output A_FXBUS2 as in the first channel, - * we use an auxiliary register, delaying the value by one - * sample - */ - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(2) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x1), A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(4) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x2), A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(6) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x3), A_C_00000000, A_C_00000000); - /* For 96kHz mode */ - /* Left ADC in. 2 of 2 */ - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(0x8) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x4), A_C_00000000, A_C_00000000); - /* Right ADC in 2 of 2 */ - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(0xa) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x5), A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(0xc) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x6), A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr - 1), A_FXBUS2(0xe) ); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x7), A_C_00000000, A_C_00000000); - /* Pavel Hofman - we still have voices, A_FXBUS2s, and - * A_P16VINs available - - * let's add 8 more capture channels - total of 16 - */ - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x10)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x8), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x12)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0x9), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x14)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xa), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x16)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xb), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x18)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xc), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x1a)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xd), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x1c)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xe), - A_C_00000000, A_C_00000000); - gpr_map[gpr++] = 0x00000000; - snd_emu10k1_audigy_dsp_convert_32_to_2x16(icode, &ptr, tmp, - bit_shifter16, - A_GPR(gpr - 1), - A_FXBUS2(0x1e)); - A_OP(icode, &ptr, iACC3, A_GPR(gpr - 1), A_P16VIN(0xf), - A_C_00000000, A_C_00000000); + /* A_P16VIN(0) is delayed by one sample, so all other A_P16VIN channels + * will need to also be delayed; we use an auxiliary register for that. */ + for (z = 1; z < 0x10; z++) { + snd_emu10k1_audigy_dsp_convert_32_to_2x16( icode, &ptr, tmp, bit_shifter16, A_GPR(gpr), A_FXBUS2(z * 2) ); + A_OP(icode, &ptr, iACC3, A_GPR(gpr), A_P16VIN(z), A_C_00000000, A_C_00000000); + gpr_map[gpr++] = 0x00000000; + } }
#if 0
From: Bard Liao yung-chuan.liao@linux.intel.com
[ Upstream commit 289e1df00e49a229a1c924c059242e759a552f01 ]
We should use RT711_JD2_100K for on board rt711.
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com Link: https://lore.kernel.org/r/20230512173305.65399-4-pierre-louis.bossart@linux.... Signed-off-by: Mark Brown <broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/intel/boards/sof_sdw.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c index f5d8f7951cfc3..91a7cb33042d8 100644 --- a/sound/soc/intel/boards/sof_sdw.c +++ b/sound/soc/intel/boards/sof_sdw.c @@ -199,6 +199,14 @@ static const struct dmi_system_id sof_sdw_quirk_table[] = { SOF_RT715_DAI_ID_FIX | SOF_SDW_PCH_DMIC), }, + { + .callback = sof_sdw_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"), + DMI_MATCH(DMI_PRODUCT_NAME, "Meteor Lake Client Platform"), + }, + .driver_data = (void *)(RT711_JD2_100K), + }, {} };
From: Peter Ujfalusi peter.ujfalusi@linux.intel.com
[ Upstream commit dfe25fea968dc4884e12d471c8263f0f611b380a ]
We should use RT711_JD2_100K for on board rt711
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com Link: https://lore.kernel.org/r/20230512173305.65399-9-pierre-louis.bossart@linux.... Signed-off-by: Mark Brown <broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/intel/boards/sof_sdw.c | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c index 91a7cb33042d8..30cc8bbceb79b 100644 --- a/sound/soc/intel/boards/sof_sdw.c +++ b/sound/soc/intel/boards/sof_sdw.c @@ -207,6 +207,15 @@ static const struct dmi_system_id sof_sdw_quirk_table[] = { }, .driver_data = (void *)(RT711_JD2_100K), }, + /* LunarLake devices */ + { + .callback = sof_sdw_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"), + DMI_MATCH(DMI_PRODUCT_NAME, "Lunar Lake Client Platform"), + }, + .driver_data = (void *)(RT711_JD2_100K), + }, {} };
From: Sumit Gupta sumitg@nvidia.com
[ Upstream commit 205b3d02d57ce6dce96f6d2b9c230f56a9bf9817 ]
Add check to fix the possible array out of bounds violation by making speed equal to GEN1_CORE_CLK_FREQ when its value is more than the size of "pcie_gen_freq" array. This array has size of four but possible speed (CLS) values are from "0 to 0xF". So, "speed - 1" values are "-1 to 0xE".
Suggested-by: Bjorn Helgaas helgaas@kernel.org Signed-off-by: Sumit Gupta sumitg@nvidia.com Link: https://lore.kernel.org/lkml/72b9168b-d4d6-4312-32ea-69358df2f2d0@nvidia.com... Acked-by: Lorenzo Pieralisi lpieralisi@kernel.org Signed-off-by: Thierry Reding treding@nvidia.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/pci/controller/dwc/pcie-tegra194.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c index 1222f5749bc67..a215777df96c7 100644 --- a/drivers/pci/controller/dwc/pcie-tegra194.c +++ b/drivers/pci/controller/dwc/pcie-tegra194.c @@ -239,6 +239,7 @@ #define EP_STATE_ENABLED 1
static const unsigned int pcie_gen_freq[] = { + GEN1_CORE_CLK_FREQ, /* PCI_EXP_LNKSTA_CLS == 0; undefined */ GEN1_CORE_CLK_FREQ, GEN2_CORE_CLK_FREQ, GEN3_CORE_CLK_FREQ, @@ -470,7 +471,11 @@ static irqreturn_t tegra_pcie_ep_irq_thread(int irq, void *arg)
speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) & PCI_EXP_LNKSTA_CLS; - clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]); + + if (speed >= ARRAY_SIZE(pcie_gen_freq)) + speed = 0; + + clk_set_rate(pcie->core_clk, pcie_gen_freq[speed]);
/* If EP doesn't advertise L1SS, just return */ val = dw_pcie_readl_dbi(pci, pcie->cfg_link_cap_l1sub); @@ -973,7 +978,11 @@ static int tegra_pcie_dw_host_init(struct pcie_port *pp)
speed = dw_pcie_readw_dbi(pci, pcie->pcie_cap_base + PCI_EXP_LNKSTA) & PCI_EXP_LNKSTA_CLS; - clk_set_rate(pcie->core_clk, pcie_gen_freq[speed - 1]); + + if (speed >= ARRAY_SIZE(pcie_gen_freq)) + speed = 0; + + clk_set_rate(pcie->core_clk, pcie_gen_freq[speed]);
tegra_pcie_enable_interrupts(pp);
From: Oleksij Rempel o.rempel@pengutronix.de
[ Upstream commit 1d14bd943fa2bbdfda1efbcc080b298fed5f1803 ]
Fix USB-related warnings in prtrvt, prtvt7, prti6q and prtwd2 device trees by disabling unused usbphynop1 and usbphynop2 USB PHYs and providing proper configuration for the over-current detection. This fixes the following warnings with the current kernel: usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests usb_phy_generic usbphynop2: dummy supplies not allowed for exclusive requests imx_usb 2184200.usb: No over current polarity defined
By the way, fix over-current detection on usbotg port for prtvt7, prti6q and prtwd2 boards. Only prtrvt do not have OC on USB OTG port.
Signed-off-by: Oleksij Rempel o.rempel@pengutronix.de Signed-off-by: Shawn Guo shawnguo@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- arch/arm/boot/dts/imx6dl-prtrvt.dts | 4 ++++ arch/arm/boot/dts/imx6qdl-prti6q.dtsi | 11 ++++++++++- 2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6dl-prtrvt.dts b/arch/arm/boot/dts/imx6dl-prtrvt.dts index 5ac84445e9cc1..90e01de8c2c15 100644 --- a/arch/arm/boot/dts/imx6dl-prtrvt.dts +++ b/arch/arm/boot/dts/imx6dl-prtrvt.dts @@ -126,6 +126,10 @@ status = "disabled"; };
+&usbotg { + disable-over-current; +}; + &vpu { status = "disabled"; }; diff --git a/arch/arm/boot/dts/imx6qdl-prti6q.dtsi b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi index 19578f660b092..70dfa07a16981 100644 --- a/arch/arm/boot/dts/imx6qdl-prti6q.dtsi +++ b/arch/arm/boot/dts/imx6qdl-prti6q.dtsi @@ -69,6 +69,7 @@ vbus-supply = <®_usb_h1_vbus>; phy_type = "utmi"; dr_mode = "host"; + disable-over-current; status = "okay"; };
@@ -78,10 +79,18 @@ pinctrl-0 = <&pinctrl_usbotg>; phy_type = "utmi"; dr_mode = "host"; - disable-over-current; + over-current-active-low; status = "okay"; };
+&usbphynop1 { + status = "disabled"; +}; + +&usbphynop2 { + status = "disabled"; +}; + &usdhc1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_usdhc1>;
From: Uday M Bhat uday.m.bhat@intel.com
[ Upstream commit 164e5dc17525181c05563f0a06796f1a363801d5 ]
Add rex entry in the soundwire quirk table
Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com Signed-off-by: Bard Liao yung-chuan.liao@linux.intel.com Signed-off-by: Yong Zhi yong.zhi@intel.com Signed-off-by: Uday M Bhat uday.m.bhat@intel.com Signed-off-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Link: https://lore.kernel.org/r/20230602202225.249209-28-pierre-louis.bossart@linu... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/intel/boards/sof_sdw.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/sound/soc/intel/boards/sof_sdw.c b/sound/soc/intel/boards/sof_sdw.c index 30cc8bbceb79b..cbbb50ddc7954 100644 --- a/sound/soc/intel/boards/sof_sdw.c +++ b/sound/soc/intel/boards/sof_sdw.c @@ -207,6 +207,14 @@ static const struct dmi_system_id sof_sdw_quirk_table[] = { }, .driver_data = (void *)(RT711_JD2_100K), }, + { + .callback = sof_sdw_quirk_cb, + .matches = { + DMI_MATCH(DMI_SYS_VENDOR, "Google"), + DMI_MATCH(DMI_PRODUCT_NAME, "Rex"), + }, + .driver_data = (void *)(SOF_SDW_PCH_DMIC), + }, /* LunarLake devices */ { .callback = sof_sdw_quirk_cb,
From: Geert Uytterhoeven geert+renesas@glider.be
[ Upstream commit b407460ee99033503993ac7437d593451fcdfe44 ]
It is considered good practice to call cpu_relax() in busy loops, see Documentation/process/volatile-considered-harmful.rst. This can not only lower CPU power consumption or yield to a hyperthreaded twin processor, but also allows an architecture to mitigate hardware issues (e.g. ARM Erratum 754327 for Cortex-A9 prior to r2p0) in the architecture-specific cpu_relax() implementation.
In addition, cpu_relax() is also a compiler barrier. It is not immediately obvious that the @op argument "function" will result in an actual function call (e.g. in case of inlining).
Where a function call is a C sequence point, this is lost on inlining. Therefore, with agressive enough optimization it might be possible for the compiler to hoist the:
(val) = op(args);
"load" out of the loop because it doesn't see the value changing. The addition of cpu_relax() would inhibit this.
As the iopoll helpers lack calls to cpu_relax(), people are sometimes reluctant to use them, and may fall back to open-coded polling loops (including cpu_relax() calls) instead.
Fix this by adding calls to cpu_relax() to the iopoll helpers: - For the non-atomic case, it is sufficient to call cpu_relax() in case of a zero sleep-between-reads value, as a call to usleep_range() is a safe barrier otherwise. However, it doesn't hurt to add the call regardless, for simplicity, and for similarity with the atomic case below. - For the atomic case, cpu_relax() must be called regardless of the sleep-between-reads value, as there is no guarantee all architecture-specific implementations of udelay() handle this.
Signed-off-by: Geert Uytterhoeven geert+renesas@glider.be Acked-by: Peter Zijlstra (Intel) peterz@infradead.org Acked-by: Arnd Bergmann arnd@arndb.de Reviewed-by: Tony Lindgren tony@atomide.com Reviewed-by: Ulf Hansson ulf.hansson@linaro.org Link: https://lore.kernel.org/r/45c87bec3397fdd704376807f0eec5cc71be440f.168569281... Signed-off-by: Sasha Levin sashal@kernel.org --- include/linux/iopoll.h | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/include/linux/iopoll.h b/include/linux/iopoll.h index 2c8860e406bd8..0417360a6db9b 100644 --- a/include/linux/iopoll.h +++ b/include/linux/iopoll.h @@ -53,6 +53,7 @@ } \ if (__sleep_us) \ usleep_range((__sleep_us >> 2) + 1, __sleep_us); \ + cpu_relax(); \ } \ (cond) ? 0 : -ETIMEDOUT; \ }) @@ -95,6 +96,7 @@ } \ if (__delay_us) \ udelay(__delay_us); \ + cpu_relax(); \ } \ (cond) ? 0 : -ETIMEDOUT; \ })
From: Jan Kara jack@suse.cz
[ Upstream commit 6a4e3363792e30177cc3965697e34ddcea8b900b ]
When add_dquot_ref() fails (usually due to IO error or ENOMEM), we want to disable quotas we are trying to enable. However dquot_disable() call was passed just the flags we are enabling so in case flags == DQUOT_USAGE_ENABLED dquot_disable() call will just fail with EINVAL instead of properly disabling quotas. Fix the problem by always passing DQUOT_LIMITS_ENABLED | DQUOT_USAGE_ENABLED to dquot_disable() in this case.
Reported-and-tested-by: Ye Bin yebin10@huawei.com Reported-by: syzbot+e633c79ceaecbf479854@syzkaller.appspotmail.com Signed-off-by: Jan Kara jack@suse.cz Message-Id: 20230605140731.2427629-2-yebin10@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/quota/dquot.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index ad255f8ab5c55..135984a1a52f4 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -2415,7 +2415,8 @@ int dquot_load_quota_sb(struct super_block *sb, int type, int format_id,
error = add_dquot_ref(sb, type); if (error) - dquot_disable(sb, type, flags); + dquot_disable(sb, type, + DQUOT_USAGE_ENABLED | DQUOT_LIMITS_ENABLED);
return error; out_fmt:
From: Ye Bin yebin10@huawei.com
[ Upstream commit d6a95db3c7ad160bc16b89e36449705309b52bcb ]
There's issue as follows when do fault injection: WARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0 Modules linked in: CPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541 RIP: 0010:dquot_disable+0x13b7/0x18c0 RSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980 RDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002 RBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000 R10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130 R13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118 FS: 00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> dquot_load_quota_sb+0xd53/0x1060 dquot_resume+0x172/0x230 ext4_reconfigure+0x1dc6/0x27b0 reconfigure_super+0x515/0xa90 __x64_sys_fsconfig+0xb19/0xd20 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Above issue may happens as follows: ProcessA ProcessB ProcessC sys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_suspend -> suspend all type quota
sys_fsconfig vfs_fsconfig_locked reconfigure_super ext4_remount dquot_resume ret = dquot_load_quota_sb add_dquot_ref do_open -> open file O_RDWR vfs_open do_dentry_open get_write_access atomic_inc_unless_negative(&inode->i_writecount) ext4_file_open dquot_file_open dquot_initialize __dquot_initialize dqget atomic_inc(&dquot->dq_count);
__dquot_initialize __dquot_initialize dqget if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) ext4_acquire_dquot -> Return error DQ_ACTIVE_B flag isn't set dquot_disable invalidate_dquots if (atomic_read(&dquot->dq_count)) dqgrab WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &dquot->dq_flags)) -> Trigger warning
In the above scenario, 'dquot->dq_flags' has no DQ_ACTIVE_B is normal when dqgrab(). To solve above issue just replace the dqgrab() use in invalidate_dquots() with atomic_inc(&dquot->dq_count).
Signed-off-by: Ye Bin yebin10@huawei.com Signed-off-by: Jan Kara jack@suse.cz Message-Id: 20230605140731.2427629-3-yebin10@huawei.com Signed-off-by: Sasha Levin sashal@kernel.org --- fs/quota/dquot.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/quota/dquot.c b/fs/quota/dquot.c index 135984a1a52f4..8d0cd68fc90a4 100644 --- a/fs/quota/dquot.c +++ b/fs/quota/dquot.c @@ -557,7 +557,7 @@ static void invalidate_dquots(struct super_block *sb, int type) continue; /* Wait for dquot users */ if (atomic_read(&dquot->dq_count)) { - dqgrab(dquot); + atomic_inc(&dquot->dq_count); spin_unlock(&dq_list_lock); /* * Once dqput() wakes us up, we know it's time to free
From: Yanteng Si siyanteng@loongson.cn
[ Upstream commit 28bd137a3c8e105587ba8c55b68ef43b519b270f ]
Add the new PCI ID 0x0014 0x7a07 and the new PCI ID 0x0014 0x7a37 Loongson HDA controller.
Signed-off-by: Yanteng Si siyanteng@loongson.cn Acked-by: Huacai Chen chenhuacai@loongson.cn Link: https://lore.kernel.org/r/993587483b9509796b29a416f257fcfb4b15c6ea.168612880... Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Sasha Levin sashal@kernel.org --- include/linux/pci_ids.h | 3 +++ sound/hda/hdac_device.c | 1 + sound/pci/hda/hda_intel.c | 7 +++++++ sound/pci/hda/patch_hdmi.c | 1 + 4 files changed, 12 insertions(+)
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 4b34a5c125999..84cb7b32aa26f 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -153,6 +153,9 @@
#define PCI_VENDOR_ID_LOONGSON 0x0014
+#define PCI_DEVICE_ID_LOONGSON_HDA 0x7a07 +#define PCI_DEVICE_ID_LOONGSON_HDMI 0x7a37 + #define PCI_VENDOR_ID_TTTECH 0x0357 #define PCI_DEVICE_ID_TTTECH_MC322 0x000a
diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index bfd8585776767..5315a3eb114ee 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -645,6 +645,7 @@ struct hda_vendor_id { };
static const struct hda_vendor_id hda_vendor_ids[] = { + { 0x0014, "Loongson" }, { 0x1002, "ATI" }, { 0x1013, "Cirrus Logic" }, { 0x1057, "Motorola" }, diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c index 1f641712233ef..13226f4f2d119 100644 --- a/sound/pci/hda/hda_intel.c +++ b/sound/pci/hda/hda_intel.c @@ -274,6 +274,7 @@ enum { AZX_DRIVER_CTHDA, AZX_DRIVER_CMEDIA, AZX_DRIVER_ZHAOXIN, + AZX_DRIVER_LOONGSON, AZX_DRIVER_GENERIC, AZX_NUM_DRIVERS, /* keep this as last entry */ }; @@ -397,6 +398,7 @@ static const char * const driver_short_names[] = { [AZX_DRIVER_CTHDA] = "HDA Creative", [AZX_DRIVER_CMEDIA] = "HDA C-Media", [AZX_DRIVER_ZHAOXIN] = "HDA Zhaoxin", + [AZX_DRIVER_LOONGSON] = "HDA Loongson", [AZX_DRIVER_GENERIC] = "HD-Audio Generic", };
@@ -2838,6 +2840,11 @@ static const struct pci_device_id azx_ids[] = { .driver_data = AZX_DRIVER_GENERIC | AZX_DCAPS_PRESET_ATI_HDMI }, /* Zhaoxin */ { PCI_DEVICE(0x1d17, 0x3288), .driver_data = AZX_DRIVER_ZHAOXIN }, + /* Loongson HDAudio*/ + {PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_HDA), + .driver_data = AZX_DRIVER_LOONGSON }, + {PCI_DEVICE(PCI_VENDOR_ID_LOONGSON, PCI_DEVICE_ID_LOONGSON_HDMI), + .driver_data = AZX_DRIVER_LOONGSON }, { 0, } }; MODULE_DEVICE_TABLE(pci, azx_ids); diff --git a/sound/pci/hda/patch_hdmi.c b/sound/pci/hda/patch_hdmi.c index c19afe4861949..5ff7e93024154 100644 --- a/sound/pci/hda/patch_hdmi.c +++ b/sound/pci/hda/patch_hdmi.c @@ -4307,6 +4307,7 @@ static int patch_gf_hdmi(struct hda_codec *codec) * patch entries */ static const struct hda_device_id snd_hda_id_hdmi[] = { +HDA_CODEC_ENTRY(0x00147a47, "Loongson HDMI", patch_generic_hdmi), HDA_CODEC_ENTRY(0x1002793c, "RS600 HDMI", patch_atihdmi), HDA_CODEC_ENTRY(0x10027919, "RS600 HDMI", patch_atihdmi), HDA_CODEC_ENTRY(0x1002791a, "RS690/780 HDMI", patch_atihdmi),
From: gaoxu gaoxu2@hihonor.com
[ Upstream commit 51ff97d54f02b4444dfc42e380ac4c058e12d5dd ]
If dma_direct_alloc() alloc memory in size of 64MB, the inner function dma_common_contiguous_remap() will allocate 128KB memory by invoking the function kmalloc_array(). and the kmalloc_array seems to fail to try to allocate 128KB mem.
Call trace: [14977.928623] qcrosvm: page allocation failure: order:5, mode:0x40cc0 [14977.928638] dump_backtrace.cfi_jt+0x0/0x8 [14977.928647] dump_stack_lvl+0x80/0xb8 [14977.928652] warn_alloc+0x164/0x200 [14977.928657] __alloc_pages_slowpath+0x9f0/0xb4c [14977.928660] __alloc_pages+0x21c/0x39c [14977.928662] kmalloc_order+0x48/0x108 [14977.928666] kmalloc_order_trace+0x34/0x154 [14977.928668] __kmalloc+0x548/0x7e4 [14977.928673] dma_direct_alloc+0x11c/0x4f8 [14977.928678] dma_alloc_attrs+0xf4/0x138 [14977.928680] gh_vm_ioctl_set_fw_name+0x3c4/0x610 [gunyah] [14977.928698] gh_vm_ioctl+0x90/0x14c [gunyah] [14977.928705] __arm64_sys_ioctl+0x184/0x210
work around by doing kvmalloc_array instead.
Signed-off-by: Gao Xu gaoxu2@hihonor.com Reviewed-by: Suren Baghdasaryan surenb@google.com Signed-off-by: Christoph Hellwig hch@lst.de Signed-off-by: Sasha Levin sashal@kernel.org --- kernel/dma/remap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/dma/remap.c b/kernel/dma/remap.c index 905c3fa005f10..5bff061993102 100644 --- a/kernel/dma/remap.c +++ b/kernel/dma/remap.c @@ -43,13 +43,13 @@ void *dma_common_contiguous_remap(struct page *page, size_t size, void *vaddr; int i;
- pages = kmalloc_array(count, sizeof(struct page *), GFP_KERNEL); + pages = kvmalloc_array(count, sizeof(struct page *), GFP_KERNEL); if (!pages) return NULL; for (i = 0; i < count; i++) pages[i] = nth_page(page, i); vaddr = vmap(pages, count, VM_DMA_COHERENT, prot); - kfree(pages); + kvfree(pages);
return vaddr; }
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c index 45b1f00c59680..c19f472ec60da 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c @@ -2155,6 +2155,7 @@ struct amdgpu_bo_va *amdgpu_vm_bo_add(struct amdgpu_device *adev, amdgpu_vm_bo_base_init(&bo_va->base, vm, bo);
bo_va->ref_count = 1; + bo_va->last_pt_update = dma_fence_get_stub(); INIT_LIST_HEAD(&bo_va->valids); INIT_LIST_HEAD(&bo_va->invalids);
@@ -2867,7 +2868,8 @@ int amdgpu_vm_init(struct amdgpu_device *adev, struct amdgpu_vm *vm, vm->update_funcs = &amdgpu_vm_cpu_funcs; else vm->update_funcs = &amdgpu_vm_sdma_funcs; - vm->last_update = NULL; + + vm->last_update = dma_fence_get_stub(); vm->last_unlocked = dma_fence_get_stub();
mutex_init(&vm->eviction_lock); @@ -3042,7 +3044,7 @@ int amdgpu_vm_make_compute(struct amdgpu_device *adev, struct amdgpu_vm *vm, vm->update_funcs = &amdgpu_vm_sdma_funcs; } dma_fence_put(vm->last_update); - vm->last_update = NULL; + vm->last_update = dma_fence_get_stub(); vm->is_compute_context = true;
if (vm->pasid) {
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos, likely from dma_fence_is_later because the stub fence is on a different timeline:
[ 273.334767] WARNING: CPU: 1 PID: 13383 at include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd [ 273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211 snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231 ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211 iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 [ 273.334795] videobuf2_common joydev [ 273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G W 5.10.192-23384-g3d3f0f0c5e4f #1 fe1e7e3b7510aa7b8e01701478119255f825a36f [ 273.334800] Hardware name: Google Dewatt/Dewatt, BIOS Google_Dewatt.14500.347.0 03/30/2023 [ 273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd [ 273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26 8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b 38 e8 [ 273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293 [ 273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000 [ 273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918 [ 273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0 [ 273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098 [ 273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000 [ 273.334814] FS: 00007e70f8694640(0000) GS:ffff8aa4e6080000(0000) knlGS:0000000000000000 [ 273.334816] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0 [ 273.334818] PKRU: 55555554 [ 273.334819] Call Trace: [ 273.334822] ? __warn+0xa3/0x131 [ 273.334824] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334826] ? report_bug+0x97/0xfa [ 273.334829] ? handle_bug+0x41/0x66 [ 273.334832] ? exc_invalid_op+0x1b/0x72 [ 273.334835] ? asm_exc_invalid_op+0x12/0x20 [ 273.334837] ? native_sched_clock+0x9a/0x9a [ 273.334840] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334843] amdgpu_sync_vm_fence+0x23/0x39 [ 273.334846] amdgpu_cs_ioctl+0x1782/0x1e56 [ 273.334851] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334854] drm_ioctl_kernel+0xdf/0x150 [ 273.334858] drm_ioctl+0x1f5/0x3d2 [ 273.334928] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334932] amdgpu_drm_ioctl+0x49/0x81 [ 273.334935] __x64_sys_ioctl+0x7d/0xc8 [ 273.334937] do_syscall_64+0x42/0x54 [ 273.334939] entry_SYSCALL_64_after_hwframe+0x4a/0xaf [ 273.334941] RIP: 0033:0x7e70ff797649 [ 273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 00 [ 273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649 [ 273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013 [ 273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340 [ 273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444 [ 273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013 [ 273.334954] ---[ end trace fc066a0fcea39e8c ]---
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
Regards, Christian.
, likely from dma_fence_is_later because the stub fence is on a different timeline:
[ 273.334767] WARNING: CPU: 1 PID: 13383 at include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd [ 273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211 snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231 ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211 iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 [ 273.334795] videobuf2_common joydev [ 273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G W 5.10.192-23384-g3d3f0f0c5e4f #1 fe1e7e3b7510aa7b8e01701478119255f825a36f [ 273.334800] Hardware name: Google Dewatt/Dewatt, BIOS Google_Dewatt.14500.347.0 03/30/2023 [ 273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd [ 273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26 8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b 38 e8 [ 273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293 [ 273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000 [ 273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918 [ 273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0 [ 273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098 [ 273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000 [ 273.334814] FS: 00007e70f8694640(0000) GS:ffff8aa4e6080000(0000) knlGS:0000000000000000 [ 273.334816] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0 [ 273.334818] PKRU: 55555554 [ 273.334819] Call Trace: [ 273.334822] ? __warn+0xa3/0x131 [ 273.334824] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334826] ? report_bug+0x97/0xfa [ 273.334829] ? handle_bug+0x41/0x66 [ 273.334832] ? exc_invalid_op+0x1b/0x72 [ 273.334835] ? asm_exc_invalid_op+0x12/0x20 [ 273.334837] ? native_sched_clock+0x9a/0x9a [ 273.334840] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334843] amdgpu_sync_vm_fence+0x23/0x39 [ 273.334846] amdgpu_cs_ioctl+0x1782/0x1e56 [ 273.334851] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334854] drm_ioctl_kernel+0xdf/0x150 [ 273.334858] drm_ioctl+0x1f5/0x3d2 [ 273.334928] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334932] amdgpu_drm_ioctl+0x49/0x81 [ 273.334935] __x64_sys_ioctl+0x7d/0xc8 [ 273.334937] do_syscall_64+0x42/0x54 [ 273.334939] entry_SYSCALL_64_after_hwframe+0x4a/0xaf [ 273.334941] RIP: 0033:0x7e70ff797649 [ 273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 00 [ 273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649 [ 273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013 [ 273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340 [ 273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444 [ 273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013 [ 273.334954] ---[ end trace fc066a0fcea39e8c ]---
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Am 31.08.23 um 12:56 schrieb Greg KH:
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Could we prevent patches from being backported by adding a Fixes: tag?
Thanks, Christian.
On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
Am 31.08.23 um 12:56 schrieb Greg KH:
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Could we prevent patches from being backported by adding a Fixes: tag?
Yes, that will show exactly where the patch should be backported to.
thanks,
greg k-h
On Thu, Aug 31, 2023 at 7:01 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
Am 31.08.23 um 12:56 schrieb Greg KH:
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Could we prevent patches from being backported by adding a Fixes: tag?
Yes, that will show exactly where the patch should be backported to.
This is also AUTOSEL'ed to 5.15. That might need a revert as well, depending on when the amdgpu feature landed.
thanks,
greg k-h
Am 31.08.23 um 20:55 schrieb Chia-I Wu:
On Thu, Aug 31, 2023 at 7:01 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
Am 31.08.23 um 12:56 schrieb Greg KH:
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote: > From: Lang Yu Lang.Yu@amd.com > > [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ] > > When using cpu to update page tables, vm update fences are unused. > Install stub fence into these fence pointers instead of NULL > to avoid NULL dereference when calling dma_fence_wait() on them. > > Suggested-by: Christian König christian.koenig@amd.com > Signed-off-by: Lang Yu Lang.Yu@amd.com > Reviewed-by: Christian König christian.koenig@amd.com > Signed-off-by: Alex Deucher alexander.deucher@amd.com > Signed-off-by: Sasha Levin sashal@kernel.org > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) We start getting this warning spew on chromeos
Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Could we prevent patches from being backported by adding a Fixes: tag?
Yes, that will show exactly where the patch should be backported to.
This is also AUTOSEL'ed to 5.15. That might need a revert as well, depending on when the amdgpu feature landed.
Both the feature and the bug fix landed in 6.5.
The bug fix should have never been backported to any older kernel at all as far as I can see.
Regards, Christian.
thanks,
greg k-h
On 01/09/2023 07:02, Christian König wrote:
Am 31.08.23 um 20:55 schrieb Chia-I Wu:
On Thu, Aug 31, 2023 at 7:01 AM Greg KH gregkh@linuxfoundation.org wrote:
On Thu, Aug 31, 2023 at 03:26:28PM +0200, Christian König wrote:
Am 31.08.23 um 12:56 schrieb Greg KH:
On Thu, Aug 31, 2023 at 12:27:27PM +0200, Christian König wrote:
Am 30.08.23 um 20:53 schrieb Chia-I Wu: > On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org > wrote: >> From: Lang Yu Lang.Yu@amd.com >> >> [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ] >> >> When using cpu to update page tables, vm update fences are unused. >> Install stub fence into these fence pointers instead of NULL >> to avoid NULL dereference when calling dma_fence_wait() on them. >> >> Suggested-by: Christian König christian.koenig@amd.com >> Signed-off-by: Lang Yu Lang.Yu@amd.com >> Reviewed-by: Christian König christian.koenig@amd.com >> Signed-off-by: Alex Deucher alexander.deucher@amd.com >> Signed-off-by: Sasha Levin sashal@kernel.org >> --- >> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- >> 1 file changed, 4 insertions(+), 2 deletions(-) > We start getting this warning spew on chromeos Yeah because the older kernels still kept track of the last VM fence in the syncobj.
This patch here should probably not have been back ported.
Why was that done anyway? The upstream commit doesn't have a CC stable and this is only a bug fix for a new feature not present on older kernels.
It is part of the AUTOSEL process.
Could we prevent patches from being backported by adding a Fixes: tag?
Yes, that will show exactly where the patch should be backported to.
This is also AUTOSEL'ed to 5.15. That might need a revert as well, depending on when the amdgpu feature landed.
Both the feature and the bug fix landed in 6.5.
The bug fix should have never been backported to any older kernel at all as far as I can see.
Regards, Christian.
I can confirm I've also started to get this warning hundreds of times per second having upgraded from 5.15.123 to 5.15.130. There's also a report from someone else of exactly the same on 5.15.128, here: https://gitlab.freedesktop.org/drm/amd/-/issues/2820
Eddie
On Wed, Aug 30, 2023 at 11:53:29AM -0700, Chia-I Wu wrote:
On Sun, Jul 23, 2023 at 6:24 PM Sasha Levin sashal@kernel.org wrote:
From: Lang Yu Lang.Yu@amd.com
[ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ]
When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them.
Suggested-by: Christian König christian.koenig@amd.com Signed-off-by: Lang Yu Lang.Yu@amd.com Reviewed-by: Christian König christian.koenig@amd.com Signed-off-by: Alex Deucher alexander.deucher@amd.com Signed-off-by: Sasha Levin sashal@kernel.org
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
We start getting this warning spew on chromeos, likely from dma_fence_is_later because the stub fence is on a different timeline:
[ 273.334767] WARNING: CPU: 1 PID: 13383 at include/linux/dma-fence.h:478 amdgpu_sync_keep_later+0x95/0xbd [ 273.334769] Modules linked in: snd_seq_dummy snd_seq snd_seq_device bridge stp llc tun vhost_vsock vhost vhost_iotlb vmw_vsock_virtio_transport_common vsock 8021q veth lzo_rle lzo_compress zram uinput snd_acp_sof_mach snd_acp_mach snd_soc_dmic xt_cgroup rfcomm xt_MASQUERADE cmac algif_hash algif_skcipher af_alg btusb btrtl btintel btbcm rtw89_8852ae rtw89_pci rtw89_8852a rtw89_core snd_sof_amd_renoir snd_sof_xtensa_dsp snd_sof_amd_acp snd_acp_pci snd_acp_config snd_soc_acpi snd_pci_acp3x snd_sof_pci snd_sof snd_hda_codec_hdmi snd_sof_utils snd_hda_intel mac80211 snd_intel_dspcfg snd_hda_codec cros_ec_typec snd_hwdep roles snd_hda_core typec snd_soc_rt5682s snd_soc_rt1019 snd_soc_rl6231 ip6table_nat i2c_piix4 fuse bluetooth ecdh_generic ecc cfg80211 iio_trig_sysfs cros_ec_lid_angle cros_ec_sensors cros_ec_sensors_core industrialio_triggered_buffer kfifo_buf industrialio cros_ec_sensorhub r8153_ecm cdc_ether usbnet r8152 mii uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 [ 273.334795] videobuf2_common joydev [ 273.334799] CPU: 1 PID: 13383 Comm: chrome:cs0 Tainted: G W 5.10.192-23384-g3d3f0f0c5e4f #1 fe1e7e3b7510aa7b8e01701478119255f825a36f [ 273.334800] Hardware name: Google Dewatt/Dewatt, BIOS Google_Dewatt.14500.347.0 03/30/2023 [ 273.334802] RIP: 0010:amdgpu_sync_keep_later+0x95/0xbd [ 273.334804] Code: 00 00 b8 01 00 00 00 f0 0f c1 43 38 85 c0 74 26 8d 48 01 09 c1 78 24 49 89 1e 5b 41 5e 5d c3 cc cc cc cc e8 4a 94 ac ff eb ce <0f> 0b 49 8b 06 48 85 c0 75 af eb c2 be 02 00 00 00 48 8d 7b 38 e8 [ 273.334805] RSP: 0018:ffffb222c1817b50 EFLAGS: 00010293 [ 273.334807] RAX: ffffffff89bfc838 RBX: ffff8aa425e9ed00 RCX: 0000000000000000 [ 273.334808] RDX: ffff8aa426156a98 RSI: ffff8aa425e9ed00 RDI: ffff8aa432518918 [ 273.334810] RBP: ffffb222c1817b60 R08: ffff8aa43ca6c0a0 R09: ffff8aa33af3c9a0 [ 273.334811] R10: fffffcf8c5986600 R11: ffffffff87a00fce R12: 0000000000000098 [ 273.334812] R13: 00000000005e2a00 R14: ffff8aa432518918 R15: 0000000000000000 [ 273.334814] FS: 00007e70f8694640(0000) GS:ffff8aa4e6080000(0000) knlGS:0000000000000000 [ 273.334816] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 273.334817] CR2: 00007e70ea049020 CR3: 0000000178e6e000 CR4: 0000000000750ee0 [ 273.334818] PKRU: 55555554 [ 273.334819] Call Trace: [ 273.334822] ? __warn+0xa3/0x131 [ 273.334824] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334826] ? report_bug+0x97/0xfa [ 273.334829] ? handle_bug+0x41/0x66 [ 273.334832] ? exc_invalid_op+0x1b/0x72 [ 273.334835] ? asm_exc_invalid_op+0x12/0x20 [ 273.334837] ? native_sched_clock+0x9a/0x9a [ 273.334840] ? amdgpu_sync_keep_later+0x95/0xbd [ 273.334843] amdgpu_sync_vm_fence+0x23/0x39 [ 273.334846] amdgpu_cs_ioctl+0x1782/0x1e56 [ 273.334851] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334854] drm_ioctl_kernel+0xdf/0x150 [ 273.334858] drm_ioctl+0x1f5/0x3d2 [ 273.334928] ? amdgpu_cs_report_moved_bytes+0x5f/0x5f [ 273.334932] amdgpu_drm_ioctl+0x49/0x81 [ 273.334935] __x64_sys_ioctl+0x7d/0xc8 [ 273.334937] do_syscall_64+0x42/0x54 [ 273.334939] entry_SYSCALL_64_after_hwframe+0x4a/0xaf [ 273.334941] RIP: 0033:0x7e70ff797649 [ 273.334943] Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1d 48 8b 45 c8 64 48 2b 04 25 28 00 00 [ 273.334945] RSP: 002b:00007e70f8693170 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 273.334947] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007e70ff797649 [ 273.334948] RDX: 00007e70f8693248 RSI: 00000000c0186444 RDI: 0000000000000013 [ 273.334950] RBP: 00007e70f86931c0 R08: 00007e70f8693350 R09: 00007e70f8693340 [ 273.334951] R10: 000000000000000a R11: 0000000000000246 R12: 00000000c0186444 [ 273.334952] R13: 00007e70f8693380 R14: 00007e70f8693248 R15: 0000000000000013 [ 273.334954] ---[ end trace fc066a0fcea39e8c ]---
Thanks, I'll go revert this now.
greg k-h
This is also causing log spam on 5.15. It was included in 5.15.128 as commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching the problem.
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
This is also causing log spam on 5.15. It was included in 5.15.128 as commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching the problem.
Now reverted, thanks.
greg k-h
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
This is also causing log spam on 5.15. It was included in 5.15.128 as commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching the problem.
Confused, what should we do here?
Am 07.10.23 um 11:50 schrieb Greg KH:
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
This is also causing log spam on 5.15. It was included in 5.15.128 as commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching the problem.
Confused, what should we do here?
If this patch was backported to even more older kernels then please revert that immediately!
This patch was part of a new feature and can only work correctly with a bunch of prerequisites. If you don't have those prerequisites in your branch then it might actually cause random memory corruptions through device DMA.
And we should probably talk about why this patch was automatically selected for backporting in the first place? There is no mention that this is a fix or should be backported in the commit message or patch itself whatsoever.
Without the WARN_ON() which started to spam the logs that could have gone south pretty quickly. Random data corruption without any indicator what's causing it is not really funny.
Regards, Christian.
On Mon, Oct 09, 2023 at 02:46:40PM +0200, Christian König wrote:
Am 07.10.23 um 11:50 schrieb Greg KH:
On Sun, Sep 10, 2023 at 03:43:01PM -0500, Bryan Jennings wrote:
This is also causing log spam on 5.15. It was included in 5.15.128 as commit 4921792e04f2125b5eadef9dbe9417a8354c7eff. I encountered this and found https://gitlab.freedesktop.org/drm/amd/-/issues/2820 while researching the problem.
Confused, what should we do here?
If this patch was backported to even more older kernels then please revert that immediately!
It only went to 5.10 and 5.15 and has been reverted from both of them now.
thanks,
greg k-h
From: Marco Morandini marco.morandini@polimi.it
[ Upstream commit 0db117359e47750d8bd310d19f13e1c4ef7fc26a ]
HP Elite Presenter Mouse HID Record Descriptor shows two mouses (Repord ID 0x1 and 0x2), one keypad (Report ID 0x5), two Consumer Controls (Report IDs 0x6 and 0x3). Previous to this commit it registers one mouse, one keypad and one Consumer Control, and it was usable only as a digitl laser pointer (one of the two mouses). This patch defines the 464a USB device ID and enables the HID_QUIRK_MULTI_INPUT quirk for it, allowing to use the device both as a mouse and a digital laser pointer.
Signed-off-by: Marco Morandini marco.morandini@polimi.it Signed-off-by: Jiri Kosina jkosina@suse.cz Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/hid/hid-ids.h | 1 + drivers/hid/hid-quirks.c | 1 + 2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h index 2b658d820b800..6712d99ad80da 100644 --- a/drivers/hid/hid-ids.h +++ b/drivers/hid/hid-ids.h @@ -582,6 +582,7 @@ #define USB_DEVICE_ID_UGCI_FIGHTING 0x0030
#define USB_VENDOR_ID_HP 0x03f0 +#define USB_PRODUCT_ID_HP_ELITE_PRESENTER_MOUSE_464A 0x464a #define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a #define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a #define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c index 9f1fcbea19eb7..4229e5de06745 100644 --- a/drivers/hid/hid-quirks.c +++ b/drivers/hid/hid-quirks.c @@ -96,6 +96,7 @@ static const struct hid_device_id hid_quirks[] = { { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A096), HID_QUIRK_NO_INIT_REPORTS }, { HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A293), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL }, + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_ELITE_PRESENTER_MOUSE_464A), HID_QUIRK_MULTI_INPUT }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL }, { HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
linux-stable-mirror@lists.linaro.org
-
Bryan Jennings -
Chia-I Wu -
Christian König -
Eddie Chapman -
Greg KH -
Sasha Levin