linux-kernel - Re: [PATCH resend] arm64: dts: mediatek: mt8192: Mark scp

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:   Mon, 19 Dec 2022 09:52:23 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Matthias Brugger <matthias.bgg@...il.com>,
        Chen-Yu Tsai <wenst@...omium.org>
Cc:     Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Nícolas F . R . A . Prado 
        <nfraprado@...labora.com>, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
        "allen-kh.cheng" <allen-kh.cheng@...iatek.com>
Subject: Re: [PATCH resend] arm64: dts: mediatek: mt8192: Mark scp_adsp clock
 as broken

Il 16/12/22 14:17, Matthias Brugger ha scritto:
> 
> 
> On 01/12/2022 10:02, AngeloGioacchino Del Regno wrote:
>> Il 01/12/22 09:56, Chen-Yu Tsai ha scritto:
>>> On Wed, Nov 30, 2022 at 7:10 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@...labora.com> wrote:
>>>>
>>>> Il 30/11/22 04:17, Chen-Yu Tsai ha scritto:
>>>>> The scp_adsp clock controller is under the SCP_ADSP power domain. This
>>>>> power domain is currently not supported nor defined.
>>>>>
>>>>> Mark the clock controller as broken for now, to avoid the system from
>>>>> trying to access it, and causing the CPU or bus to stall.
>>>>>
>>>>> Fixes: 5d2b897bc6f5 ("arm64: dts: mediatek: Add mt8192 clock controllers")
>>>>> Signed-off-by: Chen-Yu Tsai <wenst@...omium.org>
>>>>
>>>> ....or we can add the ADSP power domain to actually fix this properly, which looks
>>>> like being a generally good idea :-)
>>>
>>> Sure, but that and any driver changes have to be backported, or anything
>>> touching the clocks will still break the system.
>>>
>>
>> I agree.
>>
>>> There's no reason we can't have both. I think having this one merged and
>>> backported to stable first, then adding the SCP_ADSP power domain, and tying
>>> it to the clock controller as a follow up addition works best.
>>>
>>> What do you think?
>>>
>>
>> I think that one reason to not have both is that we'd have to revert this commit
>> after the SCP_ADSP power domain is added (with the appropriate Fixes tags and/or
>> Cc stable)...
>>
>> I'd expect that entire addition to be no more than 3 commits, including the dtsi
>> one... and if it comes out as I expect, we'd be solving that issue on all of the
>> affected older versions of the kernel - the right way.
>>
>> Can we wait for... let's say, a day or two to check how that works, before taking
>> a final decision on this commit?
>>
> 
> Do I understand correctly that the correct way for now is to merge this patch until 
> we have a fixed the power domain controller?
> 
> Regards,
> Matthias

I thought that the proper fix would be going in v6.2, but apparently something
went wrong with it as it contains things that aren't upstream.

At this point, let's go with this one until the proper fix gets factored in,
which I expect to be ready for v6.3.

Cheers,
Angelo