linux-kernel - Re: [PATCH 1/3] ALSA: hda/tegra: Skip reset on BPMP devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 7 Dec 2021 17:07:26 +0300
From:   Dmitry Osipenko <digetx@...il.com>
To:     Sameer Pujar <spujar@...dia.com>, tiwai@...e.com,
        broonie@...nel.org, lgirdwood@...il.com, robh+dt@...nel.org,
        thierry.reding@...il.com, perex@...ex.cz
Cc:     jonathanh@...dia.com, alsa-devel@...a-project.org,
        devicetree@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org, stable@...r.kernel.org,
        Mohan Kumar <mkumard@...dia.com>
Subject: Re: [PATCH 1/3] ALSA: hda/tegra: Skip reset on BPMP devices

07.12.2021 15:40, Sameer Pujar пишет:
> 
> 
> On 12/7/2021 5:35 PM, Dmitry Osipenko wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> 07.12.2021 15:00, Sameer Pujar пишет:
>>>
>>> On 12/7/2021 3:52 PM, Dmitry Osipenko wrote:
>>>> 07.12.2021 09:32, Sameer Pujar пишет:
>>>>> HDA regression is recently reported on Tegra194 based platforms.
>>>>> This happens because "hda2codec_2x" reset does not really exist
>>>>> in Tegra194 and it causes probe failure. All the HDA based audio
>>>>> tests fail at the moment. This underlying issue is exposed by
>>>>> commit c045ceb5a145 ("reset: tegra-bpmp: Handle errors in BPMP
>>>>> response") which now checks return code of BPMP command response.
>>>>>
>>>>> The failure can be fixed by avoiding above reset in the driver,
>>>>> but the explicit reset is not necessary for Tegra devices which
>>>>> depend on BPMP. On such devices, BPMP ensures reset application
>>>>> during unpowergate calls. Hence skip reset on these devices
>>>>> which is applicable for Tegra186 and later.
>>>> The power domain is shared with the display, AFAICS. The point of reset
>>>> is to bring h/w into predictable state. It doesn't make sense to me to
>>>> skip the reset.
>>> Yes the power-domain is shared with display. As mentioned above,
>>> explicit reset in driver is not really necessary since BPMP is already
>>> doing it during unpowergate stage. So the h/w is already ensured to be
>>> in a good state.
>> If you'll reload the driver module, then h/w won't be reset.
> 
> How the reload case would be different? Can you please specify more
> details if you are referring to a particular scenario?

You have a shared power domain. Since power domain can be turned off
only when nobody keeps domain turned on, you now making reset of HDA
controller dependent on the state of display driver. Do you want to have
inconsistent h/w reset behaviour depending on the runtime state of
display driver?