| 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
| ||
|
Message-ID: <7eed4379-618c-46b6-3b3e-2e4c0334bf2e@codeaurora.org>
Date: Tue, 26 May 2020 22:38:09 +0530
From: Sibi Sankar <sibis@...eaurora.org>
To: Saravana Kannan <saravanak@...gle.com>,
Georgi Djakov <georgi.djakov@...aro.org>
Cc: Rob Herring <robh@...nel.org>, Viresh Kumar <vireshk@...nel.org>,
Nishanth Menon <nm@...com>, Stephen Boyd <sboyd@...nel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Matthias Kaehlcke <mka@...omium.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
Bjorn Andersson <bjorn.andersson@...aro.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Jordan Crouse <jcrouse@...eaurora.org>,
Evan Green <evgreen@...omium.org>,
Linux PM <linux-pm@...r.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v8 09/10] dt-bindings: interconnect: Add interconnect-tags
bindings
On 5/21/20 12:43 AM, Saravana Kannan wrote:
> On Wed, May 20, 2020 at 11:51 AM Sibi Sankar <sibis@...eaurora.org> wrote:
>>
>> On 2020-05-20 01:27, Saravana Kannan wrote:
>>> On Tue, May 19, 2020 at 11:58 AM Rob Herring <robh@...nel.org> wrote:
>>>>
>>>> On Tue, May 12, 2020 at 03:53:26PM +0300, Georgi Djakov wrote:
>>>>> From: Sibi Sankar <sibis@...eaurora.org>
>>>>>
>>>>> Add interconnect-tags bindings to enable passing of optional
>>>>> tag information to the interconnect framework.
>>>>>
>>>>> Signed-off-by: Sibi Sankar <sibis@...eaurora.org>
>>>>> Signed-off-by: Georgi Djakov <georgi.djakov@...aro.org>
>>>>> ---
>>>>> v8:
>>>>> * New patch, picked from here:
>>>>> https://lore.kernel.org/r/20200504202243.5476-10-sibis@codeaurora.org
>>>>>
>>>>> .../devicetree/bindings/interconnect/interconnect.txt | 5 +++++
>>>>> 1 file changed, 5 insertions(+)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/interconnect/interconnect.txt b/Documentation/devicetree/bindings/interconnect/interconnect.txt
>>>>> index 6f5d23a605b7..c1a226a934e5 100644
>>>>> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt
>>>>> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt
>>>>> @@ -55,6 +55,11 @@ interconnect-names : List of interconnect path name strings sorted in the same
>>>>> * dma-mem: Path from the device to the main memory of
>>>>> the system
>>>>>
>>>>> +interconnect-tags : List of interconnect path tags sorted in the same order as the
>>>>> + interconnects property. Consumers can append a specific tag to
>>>>> + the path and pass this information to the interconnect framework
>>>>> + to do aggregation based on the attached tag.
>>>>
>>>> Why isn't this information in the 'interconnect' arg cells?
>>>>
>>>> We have 'interconnect-names' because strings don't mix with cells. An
>>>> expanding list of 'interconnect-.*' is not a good pattern IMO.
>>
>> Rob,
>> Currently the interconnect paths
>> assume a default tag and only few
>> icc paths require tags that differ
>> from the default ones. Encoding the
>> tags in the interconnect arg cells
>> would force all paths to specify
>> the tags. I guess that's okay.
>
> I think that's the right thing. Those cells are meant to be "args" to
> the provider.
diff --git a/arch/arm64/boot/dts/qcom/sc7180.dtsi
b/arch/arm64/boot/dts/qcom/sc7180.dtsi
index ea4764f06a901..b34f024d4ab63 100644
--- a/arch/arm64/boot/dts/qcom/sc7180.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7180.dtsi
@@ -132,9 +132,8 @@ &LITTLE_CPU_SLEEP_1
capacity-dmips-mhz = <1024>;
dynamic-power-coefficient = <100>;
operating-points-v2 = <&cpu0_opp_table>;
- interconnects = <&gem_noc MASTER_APPSS_PROC
&mc_virt SLAVE_EBI1>,
+ interconnects = <&gem_noc MASTER_APPSS_PROC 3
&mc_virt SLAVE_EBI1 3>,
<&osm_l3 MASTER_OSM_L3_APPS
&osm_l3 SLAVE_OSM_L3>;
next-level-cache = <&L2_0>;
#cooling-cells = <2>;
qcom,freq-domain = <&cpufreq_hw 0>;
....
mc_virt: interconnect@...8000 {
compatible = "qcom,sc7180-mc-virt";
reg = <0 0x01638000 0 0x1000>;
- #interconnect-cells = <1>;
+ #interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
....
@@ -2216,14 +2208,14 @@ system-cache-controller@...0000 {
gem_noc: interconnect@...0000 {
compatible = "qcom,sc7180-gem-noc";
reg = <0 0x09680000 0 0x3e200>;
- #interconnect-cells = <1>;
+ #interconnect-cells = <2>;
qcom,bcm-voters = <&apps_bcm_voter>;
};
....
diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
index 294e9c58565bb..6a7a785bd90b9 100644
--- a/drivers/interconnect/core.c
+++ b/drivers/interconnect/core.c
@@ -340,7 +340,7 @@ static struct icc_node
*of_icc_get_from_provider(struct of_phandle_args *spec)
struct icc_node *node = ERR_PTR(-EPROBE_DEFER);
struct icc_provider *provider;
- if (!spec || spec->args_count != 1)
+ if (!spec || spec->args_count < 1)
return ERR_PTR(-EINVAL);
mutex_lock(&icc_lock);
@@ -469,6 +469,9 @@ struct icc_path *of_icc_get_by_index(struct device
*dev, int idx)
return ERR_PTR(-ENOMEM);
}
+ if (src_args.args_count == 2)
+ icc_set_tag(path, src_args.args[1]);
diff: https://paste.ubuntu.com/p/sRRYhxQjsV/
Saravana/Georgi,
A few concerns here, I feel tag info as the second arg to the provider
may not be true for all socs. Does introducing soc specific of_icc_get
functions make sense?
>
>>>
>>> Also, is there an example for interconnect-tags that I missed? Is it a
>>> list of strings, numbers, etc?
>>
>> Saravana,
>> https://patchwork.kernel.org/patch/11527589/
>> ^^ is an example of interconnect-tag useage.
>
> If we actually merge interconnect-tags, I think the doc should be
> updated. Instead of having to grep around.
>
> -Saravana
>
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
Powered by blists - more mailing lists