netdev - Re: [PATCH net-next v3 06/14] net: ethernet: qualcomm: Initialize the PPE scheduler settings

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: <877b3796-3afc-4f3e-a0f5-ec1a6174a921@quicinc.com>
Date: Thu, 20 Feb 2025 22:50:08 +0800
From: Jie Luo <quic_luoj@...cinc.com>
To: Andrew Lunn <andrew@...n.ch>
CC: Andrew Lunn <andrew+netdev@...n.ch>,
        "David S. Miller"
	<davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
	<kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>, Rob Herring
	<robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley
	<conor+dt@...nel.org>, Lei Wei <quic_leiwei@...cinc.com>,
        Suruchi Agarwal
	<quic_suruchia@...cinc.com>,
        Pavithra R <quic_pavir@...cinc.com>,
        "Simon
 Horman" <horms@...nel.org>, Jonathan Corbet <corbet@....net>,
        Kees Cook
	<kees@...nel.org>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        "Philipp
 Zabel" <p.zabel@...gutronix.de>,
        <linux-arm-msm@...r.kernel.org>, <netdev@...r.kernel.org>,
        <devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-doc@...r.kernel.org>, <linux-hardening@...r.kernel.org>,
        <quic_kkumarcs@...cinc.com>, <quic_linchen@...cinc.com>,
        <srinivas.kandagatla@...aro.org>, <bartosz.golaszewski@...aro.org>,
        <john@...ozen.org>
Subject: Re: [PATCH net-next v3 06/14] net: ethernet: qualcomm: Initialize the
 PPE scheduler settings

On 2/11/2025 9:32 PM, Andrew Lunn wrote:
>> +/* Scheduler configuration for the assigning and releasing buffers for the
>> + * packet passing through PPE, which is different per SoC.
>> + */
>> +static const struct ppe_scheduler_bm_config ipq9574_ppe_sch_bm_config[] = {
>> +	{1, 0, 0, 0, 0},
>> +	{1, 1, 0, 0, 0},
>> +	{1, 0, 5, 0, 0},
>> +	{1, 1, 5, 0, 0},
>> +	{1, 0, 6, 0, 0},
>> +	{1, 1, 6, 0, 0},
>> +	{1, 0, 1, 0, 0},
>> +	{1, 1, 1, 0, 0},
> 
> Rather than add a comment what it is, add a comment what it means.

Sure, I will enhance the comment to describe the functionality for
this table better.

> 
> It also looks like the first, 3 and 4 value are fixed, so do they even
> need to be in the table? And the second value flip-flops?
> 
> 	Andrew

This array is defined to closely reflect the layout of the scheduler
BM configuration table in the PPE hardware. The value at index 0
indicates whether the entry is valid or not. In this case (for IPQ9574),
all the entries are marked as 'enabled', but for a different IPQ SoC,
some of these entries may be marked as disabled (Note: the table
structure is same for all IPQ SoCs that support PPE).

The values at index 3 and 4 indicate whether there is any backup port
configured for assigning these buffers, in the case when the primary
port is down. This option is disabled by default by the hardware
for this SoC and hence the values are marked '0'.

The value at index 1 flip flops, because for the same port, we have two
entries - one for ingress port buffer assignment (value 0) and one for
egress port buffer release (value 1).

The value at index 2 is the port number.

As a general rule, we have tried to keep the data structure definition
accurately mirror the hardware table design, for easier understanding
and debug ability of the code.

I will change the values of array index 0/1/3 to true/false to make it
more readable, thanks.