linux-kernel - Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS configuration support

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: <91f59477-1799-4db6-bcc2-3f0c5225d1c8@quicinc.com>
Date: Wed, 3 Apr 2024 14:15:20 +0530
From: Odelu Kukatla <quic_okukatla@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@...aro.org>,
        Bjorn Andersson
	<andersson@...nel.org>,
        Georgi Djakov <djakov@...nel.org>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>
CC: Kees Cook <keescook@...omium.org>, <cros-qcom-dts-watchers@...omium.org>,
        "Gustavo A . R . Silva" <gustavoars@...nel.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-pm@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-hardening@...r.kernel.org>, <quic_rlaggysh@...cinc.com>,
        <quic_mdtipton@...cinc.com>
Subject: Re: [PATCH v4 1/4] interconnect: qcom: icc-rpmh: Add QoS
 configuration support



On 3/27/2024 2:26 AM, Konrad Dybcio wrote:
> On 25.03.2024 7:16 PM, Odelu Kukatla wrote:
>> It adds QoS support for QNOC device and includes support for
>> configuring priority, priority forward disable, urgency forwarding.
>> This helps in priortizing the traffic originating from different
>> interconnect masters at NoC(Network On Chip).
>>
>> Signed-off-by: Odelu Kukatla <quic_okukatla@...cinc.com>
>> ---
> 
> [...]
> 
>>  
>> +	if (desc->config) {
>> +		struct resource *res;
>> +		void __iomem *base;
>> +
>> +		res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> +		if (!res)
>> +			goto skip_qos_config;
>> +
>> +		base = devm_ioremap_resource(dev, res);
> 
> You were asked to substitute this call like 3 times already..
> 
> devm_platform_get_and_ioremap_resource
> 
> or even better, devm_platform_ioremap_resource
> 
> [...]
> 
>> @@ -70,6 +102,7 @@ struct qcom_icc_node {
>>  	u64 max_peak[QCOM_ICC_NUM_BUCKETS];
>>  	struct qcom_icc_bcm *bcms[MAX_BCM_PER_NODE];
>>  	size_t num_bcms;
>> +	const struct qcom_icc_qosbox *qosbox;
> 
> I believe I came up with a better approach for storing this.. see [1]
> 
> Konrad
> 
> [1] https://lore.kernel.org/linux-arm-msm/20240326-topic-rpm_icc_qos_cleanup-v1-4-357e736792be@linaro.org/
> 

I see in this series, QoS parameters are moved into struct qcom_icc_desc. 
Even though we program QoS at Provider/Bus level, it is property of the node/master connected to a Bus/NoC.
It will be easier later to know which master's QoS we are programming if we add in node data.
Readability point of view,  it might be good to keep QoS parameters in node data.  

Thanks,
Odelu