netdev - Re: [net-next PATCH v5 06/14] net: dsa: qca8k: rework rgmii delay logic and scan for cpu port 6

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <6cfe6214-7b78-feca-e7ad-796a37ab369c@gmail.com>
Date:   Sun, 10 Oct 2021 19:45:50 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Ansuel Smith <ansuelsmth@...il.com>, Andrew Lunn <andrew@...n.ch>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Vladimir Oltean <olteanv@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Russell King <linux@...linux.org.uk>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH v5 06/14] net: dsa: qca8k: rework rgmii delay
 logic and scan for cpu port 6



On 10/10/2021 6:30 PM, Ansuel Smith wrote:
> Future proof commit. This switch have 2 CPU port and one valid
> configuration is first CPU port set to sgmii and second CPU port set to
> regmii-id. The current implementation detects delay only for CPU port
> zero set to rgmii and doesn't count any delay set in a secondary CPU
> port. Drop the current delay scan function and move it to the sgmii
> parser function to generilize and implicitly add support for secondary
> CPU port set to rgmii-id. Introduce new logic where delay is enabled
> also with internal delay binding declared and rgmii set as PHY mode.
> 
> Signed-off-by: Ansuel Smith <ansuelsmth@...il.com>
> ---

>   	/* We have 2 CPU port. Check them */
>   	for (port = 0; port < QCA8K_NUM_PORTS; port++) {
> @@ -1009,14 +948,56 @@ qca8k_parse_port_config(struct qca8k_priv *priv)
>   
>   		dp = dsa_to_port(priv->ds, port);
>   		port_dn = dp->dn;
> +		cpu_port_index++;

Does not this need to be bounded by QCA8K_NUM_CPU_PORTS somehow to be on 
the safe side?
-- 
Florian