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:   Thu, 9 Mar 2023 11:12:59 +0100
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Sam Protsenko <semen.protsenko@...aro.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Rob Herring <robh+dt@...nel.org>
Cc:     Alim Akhtar <alim.akhtar@...sung.com>,
        Chanwoo Choi <cw00.choi@...sung.com>,
        Chanho Park <chanho61.park@...sung.com>,
        David Virag <virag.david003@...il.com>,
        linux-arm-kernel@...ts.infradead.org,
        linux-samsung-soc@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/6] soc: samsung: pm_domains: Add Exynos850 support

Hi Sam,

On 09.03.2023 00:09, Sam Protsenko wrote:
> Power Domains in Exynos850 are not really different from other Exynos
> platforms. Enabling Exynos850 support in the PD driver is really just a
> matter of adding:
>
>      static const struct exynos_pm_domain_config exynos850_cfg = {
>          .local_pwr_cfg = 0x1,
>      };
>
> to the driver. But in the face of recent developments, e.g. this patch:
>
>      arm64: dts: exynos: move MIPI phy to PMU node in Exynos5433
>
> it looked logical to rework the PD driver a bit to support its nesting
> under the PMU node, while adding Exynos850 support to it. Initially I
> only wanted to add syscon regmap support via some dedicated property,
> but pulling PD nodes under the PMU syscon looks like more correct way.

Frankly speaking if you are changing this, you can go even further. 
Simply make PMU node a PM domain provider and specify the power domain 
as a phandle parameter. This is how it should have been done from the 
beginning, but for some unknown reasons wasn't. There is really no need 
to have a separate node for each power domain. This will also move 
implementation details to the PMU / power domain drivers and it will 
make it much easier to extend/modify it in the future. IMHO same applies 
for PHY nodes.


Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ