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] [day] [month] [year] [list]
Message-ID: <62a86fd9-5770-c32c-ad65-467940cc3ee0@collabora.com>
Date:   Thu, 9 Feb 2023 10:14:09 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Chen-Yu Tsai <wenst@...omium.org>
Cc:     mturquette@...libre.com, sboyd@...nel.org, matthias.bgg@...il.com,
        johnson.wang@...iatek.com, miles.chen@...iatek.com,
        chun-jie.chen@...iatek.com, daniel@...rotopia.org,
        fparent@...libre.com, msp@...libre.com, nfraprado@...labora.com,
        rex-bc.chen@...iatek.com, zhaojh329@...il.com,
        sam.shih@...iatek.com, edward-jw.yang@...iatek.com,
        yangyingliang@...wei.com, granquet@...libre.com,
        pablo.sun@...iatek.com, sean.wang@...iatek.com,
        chen.zhong@...iatek.com, linux-kernel@...r.kernel.org,
        linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-mediatek@...ts.infradead.org
Subject: Re: [PATCH v1 35/45] clk: mediatek: Split MT8195 clock drivers and
 allow module build

Il 09/02/23 04:46, Chen-Yu Tsai ha scritto:
> On Wed, Feb 8, 2023 at 5:00 PM AngeloGioacchino Del Regno
> <angelogioacchino.delregno@...labora.com> wrote:
>>
>> Il 08/02/23 09:28, Chen-Yu Tsai ha scritto:
>>> On Mon, Feb 6, 2023 at 11:30 PM AngeloGioacchino Del Regno
>>> <angelogioacchino.delregno@...labora.com> wrote:
>>>>
>>>> MT8195 clock drivers were encapsulated in one single (and big) Kconfig
>>>> option: there's no reason to do that, as it is totally unnecessary to
>>>> build in all or none of them.
>>>>
>>>> Split them out: keep boot-critical clocks as bool and allow choosing
>>>> non critical clocks as tristate.
>>>
>>> The power domain controller references vppsys*, vdecsys*, vdosys*, wpesys,
>>> imgsys and camsys. I'd argue that this makes these clock drivers
>>> semi-boot-critical. Maybe mfgcfg as well when we add the GPU?
>>
>> You don't need to power on additional power domains if you want to load modules
>> from a ramdisk! :-)
> 
> Right.
> 
>> Besides, you caught me: mtk-pm-domains will be my next target after clocks...
>> I don't like how it behaves in regard to probe deferrals. Specifically,
>> I dislike the fact that you either register *all domains* or *none at all*
>> (unless instantiating two different driver instances and that's ugly).
> 
> I don't really like it either, but is it possible to split probe deferrals?
> I mean, if you skip a couple power domains because the clocks aren't
> available, how do you come back to them?
> 

Honestly, I have no clue right now - I didn't even think about any possible
implementation for now... but let's see what I can come up with whenever I
get a chance to actually take a look.

Surely not before finishing work on this series, though.

> And IIRC for a clock provider that is _not_ marked as disabled in the DT,
> trying to fetch a clock from it would just give -EPROBEDEFER until
> the provider is registered.
> 

Yes it will give a probe deferral. An internal probe retry mechanism on the
power domains that couldn't probe would be one of the possible options.

Actually, we have almost endless options on how to resolve that power domains
issue, so it's not worrying me at all!

Cheers,
Angelo

> ChenYu
> 
>>>
>>> They should be bundled together at the very least. The power domain
>>> controller not probing disables all display and multimedia capabilities.
>>>
>>> Also wondering if we should have "default COMMON_CLK_MT8195" ...
>>>
>>> I suppose the same questions apply to other SoCs.
>>>
>>> ChenYu
>>
>>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ