linux-kernel - Re: [PATCH v4 0/3] interconnect: Support Samsung Exynos use-case

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: <95ac808c-aacf-8ca8-94a7-98bbdb37b39d@samsung.com>
Date:   Fri, 17 Jan 2020 14:31:49 +0900
From:   Chanwoo Choi <cw00.choi@...sung.com>
To:     Artur Świgoń <a.swigon@...sung.com>,
        linux-pm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-samsung-soc@...r.kernel.org
Cc:     georgi.djakov@...aro.org, b.zolnierkie@...sung.com,
        m.szyprowski@...sung.com, krzk@...nel.org
Subject: Re: [PATCH v4 0/3] interconnect: Support Samsung Exynos use-case

Hi Artur,

I'm concerned about that make it the separate series
without use-case like exynos-bus, exynos-drm.
If this series is applied to v5.6, it doesn't make
the problem and the patches for exynos-bus/exynos-drm
will be reviewed and then merged on later kernel version.

But, if not, the interconnect, exynos-bus and exynos-drm
patches should be merged into the same kernel version,
it must require the immutable branch among interconnect,
devfreq and exynos-drm. I think that you need to consider
it between different subsystems.

Regards,
Chanwoo Choi

On 1/16/20 11:41 PM, Artur Świgoń wrote:
> Previously posted as a part of a larger RFC: [1].
> 
> The Exynos SoC family relies on the devfreq driver for frequency
> scaling. However, a way to programmatically enforce QoS contraints
> (i.e., minimum frequency) is desired. A solution which uses the
> interconnect framework to ensure QoS is currently being developed[1].
> 
> The exynos-bus hierarchy is composed of multiple buses which are probed
> separately. Sometimes the DMC is even handled by a different driver.
> Since the exynos-bus driver is generic and supports multiple differing
> bus hierarchies, IDs for nodes (i.e. buses) are assigned dynamically. Due
> to the unspecified relative probing order, every bus registers its own
> interconnect provider.
> 
> Rationale for each patch in this series:
> * Patch 01 (exporting of_icc_get_from_provider()) makes it easy to
>   retrieve the parent node from the DT (cf. patch 05 in [1]).
> * Patch 02 (allowing #interconnect-cells = <0>) allows to remove dummy
>   node IDs from the DT.
> * Patch 03 (allowing inter-provider node pairs) is necessary to make
>   such multi-provider hierarchy work. A new approach implemented in v3
>   ensures not to break any existing drivers.
> 
> ---
> Changes since v3 (to patches in this series):
> * Improve commit messages.
> 
> ---
> Artur Świgoń
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> ---
> References:
> [1] https://patchwork.kernel.org/patch/11305287/
> 
> Artur Świgoń (3):
>   interconnect: Export of_icc_get_from_provider()
>   interconnect: Relax requirement in of_icc_get_from_provider()
>   interconnect: Allow inter-provider pairs to be configured
> 
>  drivers/interconnect/core.c           | 16 ++++++++--------
>  include/linux/interconnect-provider.h |  8 ++++++++
>  2 files changed, 16 insertions(+), 8 deletions(-)
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics