linux-kernel - [PATCH v4 1/7] interconnect: Add generic on-chip interconnect API

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]

Date:   Sat, 9 Jun 2018 22:15:41 +0300
From:   Georgi Djakov <georgi.djakov@...aro.org>
To:     Alexandre Bailon <abailon@...libre.com>
Cc:     linux-pm@...r.kernel.org, gregkh@...uxfoundation.org,
        mark.rutland@....com, lorenzo.pieralisi@....com,
        skannan@...eaurora.org, seansw@....qualcomm.com,
        khilman@...libre.com, mturquette@...libre.com, rjw@...ysocki.net,
        linux-kernel@...r.kernel.org, amit.kucheria@...aro.org,
        bjorn.andersson@...aro.org, robh+dt@...nel.org,
        linux-arm-msm@...r.kernel.org, davidai@...cinc.com,
        vincent.guittot@...aro.org, linux-arm-kernel@...ts.infradead.org
Subject: [PATCH v4 1/7] interconnect: Add generic on-chip interconnect API

Hi Alexandre,

On 8.06.18 г. 18:57, Alexandre Bailon wrote:
> On 03/09/2018 10:09 PM, Georgi Djakov wrote:
>> This patch introduce a new API to get requirements and configure the
>> interconnect buses across the entire chipset to fit with the current
>> demand.
>>
>> The API is using a consumer/provider-based model, where the providers are
>> the interconnect buses and the consumers could be various drivers.
>> The consumers request interconnect resources (path) between endpoints and
>> set the desired constraints on this data flow path. The providers receive
>> requests from consumers and aggregate these requests for all master-slave
>> pairs on that path. Then the providers configure each participating in the
>> topology node according to the requested data flow path, physical links and
>> constraints. The topology could be complicated and multi-tiered and is SoC
>> specific.
>>
>> Signed-off-by: Georgi Djakov <georgi.djakov@...aro.org>
>> ---
>>  Documentation/interconnect/interconnect.rst |  96 ++++++
>>  drivers/Kconfig                             |   2 +
>>  drivers/Makefile                            |   1 +
>>  drivers/interconnect/Kconfig                |  10 +
>>  drivers/interconnect/Makefile               |   1 +
>>  drivers/interconnect/core.c                 | 489 ++++++++++++++++++++++++++++
>>  include/linux/interconnect-provider.h       | 109 +++++++
>>  include/linux/interconnect.h                |  40 +++
>>  8 files changed, 748 insertions(+)
>>  create mode 100644 Documentation/interconnect/interconnect.rst
>>  create mode 100644 drivers/interconnect/Kconfig
>>  create mode 100644 drivers/interconnect/Makefile
>>  create mode 100644 drivers/interconnect/core.c
>>  create mode 100644 include/linux/interconnect-provider.h
>>  create mode 100644 include/linux/interconnect.h
>>

[..]

>> +
>> +/**
>> + * icc_link_create() - create a link between two nodes
>> + * @src_id: source node id
> I guess src_id has become node and is not an id anymore,
> so it should be updated.

Yes, absolutely!

>> + * @dst_id: destination node id
>> + *
>> + * Return: 0 on success, or an error code otherwise
>> + */
>> +int icc_link_create(struct icc_node *node, const int dst_id)
>> +{

Thanks,
Georgi