linux-kernel - Re: [PATCH 2/3] dt-bindings: sound: tegra: Update HDA resets

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]

Message-ID: <31e2e1d5-0d98-2a92-3ec0-496c81ac42c1@nvidia.com>
Date:   Tue, 7 Dec 2021 17:52:58 +0530
From:   Sameer Pujar <spujar@...dia.com>
To:     Dmitry Osipenko <digetx@...il.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
Subject: Re: [PATCH 2/3] dt-bindings: sound: tegra: Update HDA resets



On 12/7/2021 5:32 PM, Dmitry Osipenko wrote:
> 07.12.2021 14:04, Sameer Pujar пишет:
>>
>> On 12/7/2021 3:44 PM, Dmitry Osipenko wrote:
>>> 07.12.2021 09:32, Sameer Pujar пишет:
>>>> Tegra194 HDA has only two resets unlike the previous generations of
>>>> Tegra SoCs. Hence update the reset list accordingly.
>>>>
>>>> Fixes: 2d8f8955fe02 ("dt-bindings: tegra: Convert HDA doc to
>>>> json-schema")
>>> The original txt binding was already wrong, this "fixes" tag is wrong.
>> The text didn't document "nvidia,tegra194-hda" compatibile support until
>> the json-schema conversion happened. Perhaps the text doc was not
>> updated when Tegra194 support was added. So wouldn't this be right to
>> use json-schema commit as a base for this?
> This problem didn't exist when the binding was converted. Should be
> better to drop this tag since it doesn't add much value and creates
> confusion, IMO.

It is true that the problem was introduced recently, but from the 
documentation point of view, given the HW never had this reset it should 
not have been included in the first place. If it is not useful, I can 
just drop this tag.