-
Notifications
You must be signed in to change notification settings - Fork 140
ASoC: SOF: Intel: hda: Fix NULL pointer dereference #5650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: topic/sof-dev
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -70,12 +70,22 @@ static const struct hda_dai_widget_dma_ops * | |
| hda_dai_get_ops(struct snd_pcm_substream *substream, struct snd_soc_dai *cpu_dai) | ||
| { | ||
| struct snd_soc_dapm_widget *w = snd_soc_dai_get_widget(cpu_dai, substream->stream); | ||
| struct snd_sof_widget *swidget = w->dobj.private; | ||
| struct snd_sof_widget *swidget; | ||
| struct snd_sof_dev *sdev; | ||
| struct snd_sof_dai *sdai; | ||
|
|
||
| sdev = widget_to_sdev(w); | ||
| /* | ||
| * this is unlikely if the topology and the machine driver DAI links match. | ||
| * But if there's a missing DAI link in topology, this will prevent a NULL pointer | ||
| * dereference later on. | ||
| */ | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is such a case viable? Shouldn't it be caught before this call, maybe even in the driver? But maybe this is indeed the first location where such a check is feasible, not sure really, just clarifying
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @lyakh if the topology is clean and it matches the machine driver exactly, this isnt possible but I encountered the problem with echo ref defined in the machine driver and topology but BT only in the machine driver. This will not happen in production topologies but even for development topologies an error is more graceful than a crash
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Hrm, but how it works w/o the dai less stuff? We also have this exact case supported with function topologies when there is no monolithic present: we skip loading fragment for non supported features (like BT) to form the card, because none of the generic topologgies that we have supports BT link. Is this a fixup for the dai less series? |
||
| if (!w) { | ||
| dev_err(cpu_dai->dev, "%s: widget is NULL\n", __func__); | ||
| return NULL; | ||
| } | ||
|
|
||
| sdev = widget_to_sdev(w); | ||
| swidget = w->dobj.private; | ||
| if (!swidget) { | ||
| dev_err(sdev->dev, "%s: swidget is NULL\n", __func__); | ||
| return NULL; | ||
|
|
@@ -856,6 +866,14 @@ struct snd_soc_dai_driver skl_dai[] = { | |
| .channels_max = 4, | ||
| }, | ||
| }, | ||
| { | ||
| /* Virtual CPU DAI for Echo reference */ | ||
| .name = "Loopback Virtual Pin", | ||
| .capture = { | ||
| .channels_min = 1, | ||
| .channels_max = 2, | ||
| }, | ||
| }, | ||
| #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC) | ||
| { | ||
| .name = "iDisp1 Pin", | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -418,10 +418,10 @@ | |
| (HDA_DSP_BDL_SIZE / sizeof(struct sof_intel_dsp_bdl)) | ||
|
|
||
| /* Number of DAIs */ | ||
| #define SOF_SKL_NUM_DAIS_NOCODEC 8 | ||
| #define SOF_SKL_NUM_DAIS_NOCODEC 9 | ||
|
|
||
| #if IS_ENABLED(CONFIG_SND_SOC_SOF_HDA_AUDIO_CODEC) | ||
| #define SOF_SKL_NUM_DAIS 15 | ||
| #define SOF_SKL_NUM_DAIS 16 | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. is this a fixup or should be collected together with the dai less series?
Collaborator
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. not a fixup, keep this as a separate patch in the DAIless series at the beginning |
||
| #else | ||
| #define SOF_SKL_NUM_DAIS SOF_SKL_NUM_DAIS_NOCODEC | ||
| #endif | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ujfalusi this is to fix a conflict with BT. The BT DAI link already uses the dummy DAI and is created before the echo ref DAI in the machine driver. So ifyou use the same dummy CPU DAI for echo ref, the BT DAI link gets picked when connecting FE and BE with DPCM. One way to fix this is to create the echo ref first but then BT will be broken. So using the dummy DAI for BT and the virtual pin for echo ref is the right way to do it so that the 2 features are not mutually exclusive
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are you saying that if we resort to use dummy-dai for HDMI (because no iDisp codec) then BT will fail today also?
And this is the CPU dai, which for BT is always
"SSP%d Pin", in fact I don't see in any asoc_sdw_init_simple_dai_link() that the"snd-soc-dummy-dai"is used, but in the echoref case.Something is not adding up.