From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Cezary Rojewski <cezary.rojewski@intel.com>
Cc: alsa-devel@alsa-project.org, broonie@kernel.org, tiwai@suse.com,
Mateusz Gorski <mateusz.gorski@linux.intel.com>
Subject: Re: [PATCH] ASoC: Intel: skl_hda_dsp_generic: Fix NULLptr dereference in autosuspend delay
Date: Wed, 22 Jul 2020 14:04:28 -0500 [thread overview]
Message-ID: <edc0c832-c92b-ab95-c5e5-6bea2cf12973@linux.intel.com> (raw)
In-Reply-To: <014d8a2f-1ba7-1872-73b2-2384d908de79@intel.com>
>>> Change the string in conditional statement to "ehdaudio0D0" to ensure
>>> that only the HDAudio codec is handled by this function.
>>
>> I am not sure this is correct.
>>
>> I may be wrong, but my understanding is the following:
>>
>> Before 5bf73b1b1dec, the driver would use the first dailink of the
>> card, and in the case of devices without an HDaudio codec (e.g. Up2
>> board) it would set the auto suspend delay using that first dailink.
>> See the code in skl_hda_fill_card_info(), it reorders the dailinks
>> when HDaudio codecs are not present so if you test for 'edhaudio00'
>> you no longer allow for this HDMI-only case to be handled with
>> autosuspend.
>>
>> Kai would need to review this, so this will have to wait I am afraid.
>>
>
> So, for_each_card_rtds needs to be context aware (hdmi type). Right now,
> introduced _autosuspend_delay is causing kernel panics.
The code before 5bf73b1b1dec would use an HDMI dailink when HDaudio
codecs are not present, so I don't really see the point on being context
aware. Either this never worked or there's a side effect. In both cases,
I would kindly ask that this does not get merged before Kai is back.
next prev parent reply other threads:[~2020-07-22 19:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-22 17:35 [PATCH] ASoC: Intel: skl_hda_dsp_generic: Fix NULLptr dereference in autosuspend delay Mateusz Gorski
2020-07-22 18:24 ` Pierre-Louis Bossart
2020-07-22 18:59 ` Cezary Rojewski
2020-07-22 19:04 ` Pierre-Louis Bossart [this message]
2020-08-12 13:48 ` Kai Vehmanen
2020-08-17 14:32 ` Gorski, Mateusz
2020-08-17 16:35 ` Kai Vehmanen
2020-08-19 12:15 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=edc0c832-c92b-ab95-c5e5-6bea2cf12973@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=cezary.rojewski@intel.com \
--cc=mateusz.gorski@linux.intel.com \
--cc=tiwai@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.