[PATCH 0/2] ASoC: SOF: remove unregister calls from shutdown
This patchset is an alternative solution to problems reported by Ricardo Ribalda ribalda@chromium.org and Zhen Ni nizhen@uniontech.com, as discussed in
- "[PATCH] ALSA: core: Fix deadlock when shutdown a frozen userspace" https://mailman.alsa-project.org/pipermail/alsa-devel/2022-November/209248.h...
- "[PATCH] ASoc: SOF: Fix sof-audio-pci-intel-tgl shutdown timeout during hibernation" https://mailman.alsa-project.org/pipermail/alsa-devel/2022-December/209685.h...
It was raised by Oliver Neukum oneukum@suse.com that kernel should not let user-space stall the shutdown process in any scenario and the unregister call in current SOF shutdown code is not right.
This series reverts the ASoC SOF patch to unregister clients and the machine drivers at shutdown. To avoid bringing back old bugs, the series includes a patch to fix S5 entry on certain Intel platforms.
Kai Vehmanen (2): ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed" ASoC: SOF: Revert: "core: unregister clients and machine drivers in .shutdown"
sound/soc/sof/core.c | 9 ----- sound/soc/sof/intel/hda-dsp.c | 72 +++++++++++++++++++++++++++++++++++ sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/tgl.c | 2 +- 4 files changed, 74 insertions(+), 10 deletions(-)
base-commit: e85b1f5a9769ac30f4d2f6fb1cdcd9570c38e0c1
If system shutdown has not been completed cleanly, it is possible the DMA stream shutdown has not been done, or was not clean.
If this is the case, Intel TGL/ADL HDA platforms may fail to shutdown cleanly due to pending HDA DMA transactions. To avoid this, detect this scenario in the shutdown callback, and perform an additional controller reset. This has been tested to unblock S5 entry if this condition is hit.
Co-developed-by: Archana Patni archana.patni@intel.com Signed-off-by: Archana Patni archana.patni@intel.com Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Péter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com --- sound/soc/sof/intel/hda-dsp.c | 72 +++++++++++++++++++++++++++++++++++ sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/tgl.c | 2 +- 3 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c index 5fa29df54b42..b4eacae8564c 100644 --- a/sound/soc/sof/intel/hda-dsp.c +++ b/sound/soc/sof/intel/hda-dsp.c @@ -878,6 +878,78 @@ int hda_dsp_suspend(struct snd_sof_dev *sdev, u32 target_state) return snd_sof_dsp_set_power_state(sdev, &target_dsp_state); }
+static unsigned int hda_dsp_check_for_dma_streams(struct snd_sof_dev *sdev) +{ + struct hdac_bus *bus = sof_to_bus(sdev); + struct hdac_stream *s; + unsigned int active_streams = 0; + int sd_offset; + u32 val; + + list_for_each_entry(s, &bus->stream_list, list) { + sd_offset = SOF_STREAM_SD_OFFSET(s); + val = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR, + sd_offset); + if (val & SOF_HDA_SD_CTL_DMA_START) + active_streams |= BIT(s->index); + } + + return active_streams; +} + +static int hda_dsp_s5_quirk(struct snd_sof_dev *sdev) +{ + int ret; + + /* + * Do not assume a certain timing between the prior + * suspend flow, and running of this quirk function. + * This is needed if the controller was just put + * to reset before calling this function. + */ + usleep_range(500, 1000); + + /* + * Take controller out of reset to flush DMA + * transactions. + */ + ret = hda_dsp_ctrl_link_reset(sdev, false); + if (ret < 0) + return ret; + + usleep_range(500, 1000); + + /* Restore state for shutdown, back to reset */ + ret = hda_dsp_ctrl_link_reset(sdev, true); + if (ret < 0) + return ret; + + return ret; +} + +int hda_dsp_shutdown_dma_flush(struct snd_sof_dev *sdev) +{ + unsigned int active_streams; + int ret, ret2; + + /* check if DMA cleanup has been successful */ + active_streams = hda_dsp_check_for_dma_streams(sdev); + + sdev->system_suspend_target = SOF_SUSPEND_S3; + ret = snd_sof_suspend(sdev->dev); + + if (active_streams) { + dev_warn(sdev->dev, + "There were active DSP streams (%#x) at shutdown, trying to recover\n", + active_streams); + ret2 = hda_dsp_s5_quirk(sdev); + if (ret2 < 0) + dev_err(sdev->dev, "shutdown recovery failed (%d)\n", ret2); + } + + return ret; +} + int hda_dsp_shutdown(struct snd_sof_dev *sdev) { sdev->system_suspend_target = SOF_SUSPEND_S3; diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h index 022ce80968dd..caccaf8fba9c 100644 --- a/sound/soc/sof/intel/hda.h +++ b/sound/soc/sof/intel/hda.h @@ -592,6 +592,7 @@ int hda_dsp_resume(struct snd_sof_dev *sdev); int hda_dsp_runtime_suspend(struct snd_sof_dev *sdev); int hda_dsp_runtime_resume(struct snd_sof_dev *sdev); int hda_dsp_runtime_idle(struct snd_sof_dev *sdev); +int hda_dsp_shutdown_dma_flush(struct snd_sof_dev *sdev); int hda_dsp_shutdown(struct snd_sof_dev *sdev); int hda_dsp_set_hw_params_upon_resume(struct snd_sof_dev *sdev); void hda_dsp_dump(struct snd_sof_dev *sdev, u32 flags); diff --git a/sound/soc/sof/intel/tgl.c b/sound/soc/sof/intel/tgl.c index 30f2f49ee149..58ac3a46e6a7 100644 --- a/sound/soc/sof/intel/tgl.c +++ b/sound/soc/sof/intel/tgl.c @@ -60,7 +60,7 @@ int sof_tgl_ops_init(struct snd_sof_dev *sdev) memcpy(&sof_tgl_ops, &sof_hda_common_ops, sizeof(struct snd_sof_dsp_ops));
/* probe/remove/shutdown */ - sof_tgl_ops.shutdown = hda_dsp_shutdown; + sof_tgl_ops.shutdown = hda_dsp_shutdown_dma_flush;
if (sdev->pdata->ipc_type == SOF_IPC) { /* doorbell */
Hi kai
nit: I think you have an extra " at the end of the subject
Thanks for the patch!
On Fri, 9 Dec 2022 at 12:46, Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
If system shutdown has not been completed cleanly, it is possible the DMA stream shutdown has not been done, or was not clean.
If this is the case, Intel TGL/ADL HDA platforms may fail to shutdown cleanly due to pending HDA DMA transactions. To avoid this, detect this scenario in the shutdown callback, and perform an additional controller reset. This has been tested to unblock S5 entry if this condition is hit.
Co-developed-by: Archana Patni archana.patni@intel.com Signed-off-by: Archana Patni archana.patni@intel.com Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Péter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com
Tested-by: Ricardo Ribalda ribalda@chromium.org
sound/soc/sof/intel/hda-dsp.c | 72 +++++++++++++++++++++++++++++++++++ sound/soc/sof/intel/hda.h | 1 + sound/soc/sof/intel/tgl.c | 2 +- 3 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sof/intel/hda-dsp.c b/sound/soc/sof/intel/hda-dsp.c index 5fa29df54b42..b4eacae8564c 100644 --- a/sound/soc/sof/intel/hda-dsp.c +++ b/sound/soc/sof/intel/hda-dsp.c @@ -878,6 +878,78 @@ int hda_dsp_suspend(struct snd_sof_dev *sdev, u32 target_state) return snd_sof_dsp_set_power_state(sdev, &target_dsp_state); }
+static unsigned int hda_dsp_check_for_dma_streams(struct snd_sof_dev *sdev) +{
struct hdac_bus *bus = sof_to_bus(sdev);
struct hdac_stream *s;
unsigned int active_streams = 0;
int sd_offset;
u32 val;
list_for_each_entry(s, &bus->stream_list, list) {
sd_offset = SOF_STREAM_SD_OFFSET(s);
val = snd_sof_dsp_read(sdev, HDA_DSP_HDA_BAR,
sd_offset);
if (val & SOF_HDA_SD_CTL_DMA_START)
active_streams |= BIT(s->index);
}
return active_streams;
+}
+static int hda_dsp_s5_quirk(struct snd_sof_dev *sdev) +{
int ret;
/*
* Do not assume a certain timing between the prior
* suspend flow, and running of this quirk function.
* This is needed if the controller was just put
* to reset before calling this function.
*/
usleep_range(500, 1000);
/*
* Take controller out of reset to flush DMA
* transactions.
*/
ret = hda_dsp_ctrl_link_reset(sdev, false);
if (ret < 0)
return ret;
usleep_range(500, 1000);
/* Restore state for shutdown, back to reset */
ret = hda_dsp_ctrl_link_reset(sdev, true);
if (ret < 0)
return ret;
return ret;
+}
+int hda_dsp_shutdown_dma_flush(struct snd_sof_dev *sdev) +{
unsigned int active_streams;
int ret, ret2;
/* check if DMA cleanup has been successful */
active_streams = hda_dsp_check_for_dma_streams(sdev);
sdev->system_suspend_target = SOF_SUSPEND_S3;
ret = snd_sof_suspend(sdev->dev);
if (active_streams) {
dev_warn(sdev->dev,
"There were active DSP streams (%#x) at shutdown, trying to recover\n",
active_streams);
ret2 = hda_dsp_s5_quirk(sdev);
if (ret2 < 0)
dev_err(sdev->dev, "shutdown recovery failed (%d)\n", ret2);
}
return ret;
+}
int hda_dsp_shutdown(struct snd_sof_dev *sdev) { sdev->system_suspend_target = SOF_SUSPEND_S3; diff --git a/sound/soc/sof/intel/hda.h b/sound/soc/sof/intel/hda.h index 022ce80968dd..caccaf8fba9c 100644 --- a/sound/soc/sof/intel/hda.h +++ b/sound/soc/sof/intel/hda.h @@ -592,6 +592,7 @@ int hda_dsp_resume(struct snd_sof_dev *sdev); int hda_dsp_runtime_suspend(struct snd_sof_dev *sdev); int hda_dsp_runtime_resume(struct snd_sof_dev *sdev); int hda_dsp_runtime_idle(struct snd_sof_dev *sdev); +int hda_dsp_shutdown_dma_flush(struct snd_sof_dev *sdev); int hda_dsp_shutdown(struct snd_sof_dev *sdev); int hda_dsp_set_hw_params_upon_resume(struct snd_sof_dev *sdev); void hda_dsp_dump(struct snd_sof_dev *sdev, u32 flags); diff --git a/sound/soc/sof/intel/tgl.c b/sound/soc/sof/intel/tgl.c index 30f2f49ee149..58ac3a46e6a7 100644 --- a/sound/soc/sof/intel/tgl.c +++ b/sound/soc/sof/intel/tgl.c @@ -60,7 +60,7 @@ int sof_tgl_ops_init(struct snd_sof_dev *sdev) memcpy(&sof_tgl_ops, &sof_hda_common_ops, sizeof(struct snd_sof_dsp_ops));
/* probe/remove/shutdown */
sof_tgl_ops.shutdown = hda_dsp_shutdown;
sof_tgl_ops.shutdown = hda_dsp_shutdown_dma_flush; if (sdev->pdata->ipc_type == SOF_IPC) { /* doorbell */
-- 2.38.1
The unregister machine drivers call is not safe to do when kexec is used. Kexec-lite gets blocked with following backtrace:
[ 84.943749] Freezing user space processes ... (elapsed 0.111 seconds) done. [ 246.784446] INFO: task kexec-lite:5123 blocked for more than 122 seconds. [ 246.819035] Call Trace: [ 246.821782] <TASK> [ 246.824186] __schedule+0x5f9/0x1263 [ 246.828231] schedule+0x87/0xc5 [ 246.831779] snd_card_disconnect_sync+0xb5/0x127 ... [ 246.889249] snd_sof_device_shutdown+0xb4/0x150 [ 246.899317] pci_device_shutdown+0x37/0x61 [ 246.903990] device_shutdown+0x14c/0x1d6 [ 246.908391] kernel_kexec+0x45/0xb9
This reverts commit 83bfc7e793b555291785136c3ae86abcdc046887.
Reported-by: Ricardo Ribalda ribalda@chromium.org Cc: Ricardo Ribalda ribalda@chromium.org Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Péter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com --- sound/soc/sof/core.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c index 3e6141d03770..625977a29d8a 100644 --- a/sound/soc/sof/core.c +++ b/sound/soc/sof/core.c @@ -475,19 +475,10 @@ EXPORT_SYMBOL(snd_sof_device_remove); int snd_sof_device_shutdown(struct device *dev) { struct snd_sof_dev *sdev = dev_get_drvdata(dev); - struct snd_sof_pdata *pdata = sdev->pdata;
if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE)) cancel_work_sync(&sdev->probe_work);
- /* - * make sure clients and machine driver(s) are unregistered to force - * all userspace devices to be closed prior to the DSP shutdown sequence - */ - sof_unregister_clients(sdev); - - snd_sof_machine_unregister(sdev, pdata); - if (sdev->fw_state == SOF_FW_BOOT_COMPLETE) return snd_sof_shutdown(sdev);
On Fri, Dec 09, 2022 at 01:45:29PM +0200, Kai Vehmanen wrote:
This reverts commit 83bfc7e793b555291785136c3ae86abcdc046887.
Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read.
- /*
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
- snd_sof_machine_unregister(sdev, pdata);
I am somewhat surprised that these block on the kernel side rather than just disconnecting the kernel side of whatever userspace sees - I'd thought they were more like hotplug operations than something blocking.
Hi,
On Fri, 9 Dec 2022, Mark Brown wrote:
On Fri, Dec 09, 2022 at 01:45:29PM +0200, Kai Vehmanen wrote:
This reverts commit 83bfc7e793b555291785136c3ae86abcdc046887.
Please include human readable descriptions of things like commits and issues being discussed in e-mail in your mails, this makes them much
ack, will fix in V2.
easier for humans to read especially when they have no internet access. I do frequently catch up on my mail on flights or while otherwise travelling so this is even more pressing for me than just being about making things a bit easier to read.
- /*
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
- snd_sof_machine_unregister(sdev, pdata);
I am somewhat surprised that these block on the kernel side rather than just disconnecting the kernel side of whatever userspace sees - I'd thought they were more like hotplug operations than something blocking.
Yes, this is not so obvious. The machine unregister ends up in soc-core.c:soc_cleanup_card_resources()
--cut-- static void soc_cleanup_card_resources(struct snd_soc_card *card) { » struct snd_soc_pcm_runtime *rtd, *n;
» if (card->snd_card) » » snd_card_disconnect_sync(card->snd_card); --cut--
... and there we have the "sync" variant call that gets us in trouble with e.g. kexec().
This seems to be only user of snd_card_disconnect_sync(), but it was specifically added to fix a bug in commit 0ced7b050224 ("ASoC: soc-pcm: remove soc_pcm_private_free()").
Br, Kai
Hi Kai
Thanks for the patch. Just tested it on Alderlake-P
On Fri, 9 Dec 2022 at 12:46, Kai Vehmanen kai.vehmanen@linux.intel.com wrote:
The unregister machine drivers call is not safe to do when kexec is used. Kexec-lite gets blocked with following backtrace:
[ 84.943749] Freezing user space processes ... (elapsed 0.111 seconds) done. [ 246.784446] INFO: task kexec-lite:5123 blocked for more than 122 seconds. [ 246.819035] Call Trace: [ 246.821782] <TASK> [ 246.824186] __schedule+0x5f9/0x1263 [ 246.828231] schedule+0x87/0xc5 [ 246.831779] snd_card_disconnect_sync+0xb5/0x127 ... [ 246.889249] snd_sof_device_shutdown+0xb4/0x150 [ 246.899317] pci_device_shutdown+0x37/0x61 [ 246.903990] device_shutdown+0x14c/0x1d6 [ 246.908391] kernel_kexec+0x45/0xb9
This reverts commit 83bfc7e793b555291785136c3ae86abcdc046887.
Reported-by: Ricardo Ribalda ribalda@chromium.org Cc: Ricardo Ribalda ribalda@chromium.org Signed-off-by: Kai Vehmanen kai.vehmanen@linux.intel.com
Tested-by: Ricardo Ribalda ribalda@chromium.org
Reviewed-by: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com Reviewed-by: Péter Ujfalusi peter.ujfalusi@linux.intel.com Reviewed-by: Ranjani Sridharan ranjani.sridharan@linux.intel.com
sound/soc/sof/core.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c index 3e6141d03770..625977a29d8a 100644 --- a/sound/soc/sof/core.c +++ b/sound/soc/sof/core.c @@ -475,19 +475,10 @@ EXPORT_SYMBOL(snd_sof_device_remove); int snd_sof_device_shutdown(struct device *dev) { struct snd_sof_dev *sdev = dev_get_drvdata(dev);
struct snd_sof_pdata *pdata = sdev->pdata; if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE)) cancel_work_sync(&sdev->probe_work);
/*
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
sof_unregister_clients(sdev);
snd_sof_machine_unregister(sdev, pdata);
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE) return snd_sof_shutdown(sdev);
-- 2.38.1
On Fri, 09 Dec 2022 13:45:27 +0200, Kai Vehmanen wrote:
This patchset is an alternative solution to problems reported by Ricardo Ribalda ribalda@chromium.org and Zhen Ni nizhen@uniontech.com, as discussed in
- "[PATCH] ALSA: core: Fix deadlock when shutdown a frozen userspace"
https://mailman.alsa-project.org/pipermail/alsa-devel/2022-November/209248.h...
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed" commit: 2aa2a5ead0ee0a358bf80a2984a641d1bf2adc2a [2/2] ASoC: SOF: Revert: "core: unregister clients and machine drivers in .shutdown" commit: 44fda61d2bcfb74a942df93959e083a4e8eff75f
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
Hi, this is your Linux kernel regression tracker.
On 14.12.22 14:32, Mark Brown wrote:
On Fri, 09 Dec 2022 13:45:27 +0200, Kai Vehmanen wrote:
This patchset is an alternative solution to problems reported by Ricardo Ribalda ribalda@chromium.org and Zhen Ni nizhen@uniontech.com, as discussed in
- "[PATCH] ALSA: core: Fix deadlock when shutdown a frozen userspace"
https://mailman.alsa-project.org/pipermail/alsa-devel/2022-November/209248.h...
[...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/2] ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has failed" commit: 2aa2a5ead0ee0a358bf80a2984a641d1bf2adc2a [2/2] ASoC: SOF: Revert: "core: unregister clients and machine drivers in .shutdown" commit: 44fda61d2bcfb74a942df93959e083a4e8eff75f
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. [...]
I noticed a regression report in bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=216820
```
My laptop started to hang on hibernation (sleep and shutdown are fine). I bisected it to commit 83bfc7e793b555291785136c3ae86abcdc046887, which appears to be related to ALSA.
```
That's a commit the second patch from this series reverts. To my untrained eyes it thus looks a lot like these change will resolve the reported issue, which made me wonder:
* these patches afaics are not yet in mainline, is the plan to still send it this cycle?
* there are no "CC: <stable..." tags in these patches. Is the plan to manually ask for a backport? Or how can we get the regression fixed in older releases?
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
On Mon, Dec 19, 2022 at 10:41:41AM +0100, Thorsten Leemhuis wrote:
- there are no "CC: <stable..." tags in these patches. Is the plan to
manually ask for a backport? Or how can we get the regression fixed in older releases?
Speak to the stable maintainers I guess, or hope their bot picks the commits up.
Hi,
On Mon, 19 Dec 2022, Mark Brown wrote:
On Mon, Dec 19, 2022 at 10:41:41AM +0100, Thorsten Leemhuis wrote:
- there are no "CC: <stable..." tags in these patches. Is the plan to
manually ask for a backport? Or how can we get the regression fixed in older releases?
Speak to the stable maintainers I guess, or hope their bot picks the commits up.
thanks Thorsten for the notice. These patches do lack the "Fixes:" tag, so it's possible the bots will not pick these up. I can follow up and send these to stable if this does not happen.
Br, Kai
On Tue, Dec 20, 2022 at 01:41:01PM +0200, Kai Vehmanen wrote:
Hi,
On Mon, 19 Dec 2022, Mark Brown wrote:
On Mon, Dec 19, 2022 at 10:41:41AM +0100, Thorsten Leemhuis wrote:
- there are no "CC: <stable..." tags in these patches. Is the plan to
manually ask for a backport? Or how can we get the regression fixed in older releases?
Speak to the stable maintainers I guess, or hope their bot picks the commits up.
thanks Thorsten for the notice. These patches do lack the "Fixes:" tag, so it's possible the bots will not pick these up. I can follow up and send these to stable if this does not happen.
"Fixes:" guarantees nothing, please NEVER rely on that. As per the kernel documentation for the last 18+ years, you have to tag a commit with the "Cc: stable@..." tag to ensure that it gets picked up properly.
thanks,
greg k-h
On 20.12.22 12:41, Kai Vehmanen wrote:
On Mon, 19 Dec 2022, Mark Brown wrote:
On Mon, Dec 19, 2022 at 10:41:41AM +0100, Thorsten Leemhuis wrote:
- there are no "CC: <stable..." tags in these patches. Is the plan to
manually ask for a backport? Or how can we get the regression fixed in older releases?
Speak to the stable maintainers I guess, or hope their bot picks the commits up.
thanks Thorsten for the notice. These patches do lack the "Fixes:" tag, so it's possible the bots will not pick these up. I can follow up and send these to stable if this does not happen.
Thanks, that would be great, I try to stay out of that business, as actual developers of the code in question are in the best position to judge and handle things like this.
Ciao, Thorsten
participants (5)
-
Greg KH
-
Kai Vehmanen
-
Mark Brown
-
Ricardo Ribalda
-
Thorsten Leemhuis