linux-kernel - Re: [PATCH net-next v5 03/14] net: ethernet: qualcomm: Add PPE driver for IPQ9574 SoC

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]

Message-ID: <dc9eb276-3b61-484b-96e6-d2ac746492e5@quicinc.com>
Date: Fri, 1 Aug 2025 22:42:43 +0800
From: Luo Jie <quic_luoj@...cinc.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        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>
CC: <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>
Subject: Re: [PATCH net-next v5 03/14] net: ethernet: qualcomm: Add PPE driver
 for IPQ9574 SoC



On 7/30/2025 7:57 PM, Konrad Dybcio wrote:
> On 7/1/25 2:24 PM, Luo Jie wrote:
>>
>>
>> On 6/28/2025 12:21 AM, Konrad Dybcio wrote:
>>> On 6/26/25 4:31 PM, Luo Jie wrote:
>>>> The PPE (Packet Process Engine) hardware block is available on Qualcomm
>>>> IPQ SoC that support PPE architecture, such as IPQ9574.
>>>>
>>>> The PPE in IPQ9574 includes six integrated ethernet MAC for 6 PPE ports,
>>>> buffer management, queue management and scheduler functions. The MACs
>>>> can connect with the external PHY or switch devices using the UNIPHY PCS
>>>> block available in the SoC.
>>>>
>>>> The PPE also includes various packet processing offload capabilities
>>>> such as L3 routing and L2 bridging, VLAN and tunnel processing offload.
>>>> It also includes Ethernet DMA function for transferring packets between
>>>> ARM cores and PPE ethernet ports.
>>>>
>>>> This patch adds the base source files and Makefiles for the PPE driver
>>>> such as platform driver registration, clock initialization, and PPE
>>>> reset routines.
>>>>
>>>> Signed-off-by: Luo Jie <quic_luoj@...cinc.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> +static int ppe_clock_init_and_reset(struct ppe_device *ppe_dev)
>>>> +{
>>>> +    unsigned long ppe_rate = ppe_dev->clk_rate;
>>>> +    struct device *dev = ppe_dev->dev;
>>>> +    struct reset_control *rstc;
>>>> +    struct clk_bulk_data *clks;
>>>> +    struct clk *clk;
>>>> +    int ret, i;
>>>> +
>>>> +    for (i = 0; i < ppe_dev->num_icc_paths; i++) {
>>>> +        ppe_dev->icc_paths[i].name = ppe_icc_data[i].name;
>>>> +        ppe_dev->icc_paths[i].avg_bw = ppe_icc_data[i].avg_bw ? :
>>>> +                           Bps_to_icc(ppe_rate);
>>>> +        ppe_dev->icc_paths[i].peak_bw = ppe_icc_data[i].peak_bw ? :
>>>> +                        Bps_to_icc(ppe_rate);
>>>> +    }
>>>
>>> Can you not just set ppe_dev->icc_paths to ppe_icc_data?
>>>
>>> Konrad
>>
>> The `avg_bw` and `peak_bw` for two of the PPE ICC clocks ('ppe' and
>> 'ppe_cfg') vary across different SoCs and they need to be read from
>> platform data. They are not pre-defined in `ppe_icc_data` array.
>> Therefore, we use this format to assign `icc_paths`, allowing us to
>> accommodate cases where `avg_bw` and `peak_bw` are not predefined.
>> Hope this is fine. Thanks.
> 
> You're currently hardcoding the clock rate, which one of the comments
> suggests is where the bw values come from. Is there a formula that we
> could calculate the necessary bandwidth based on?

The clock rate for the PPE-related NoC (ICC) is fixed at 353 MHz on the
IPQ9574 platform, as confirmed by the hardware team. There is no formula
required to derive the rate.

> 
> We could then clk_get_rate() and do it dynamically

Thank you for the suggestion. Yes, we can use the PPE clock rate as the
configuration value for the PPE NoC clocks, since both operate on the
same clock tree and share the same clock rate. With this, we could use
the clk_get_rate() as you suggested to get the PPE clock rate, which
will be configured to the same rate as the PPE NoC (ICC) clocks.

> 
> Konrad