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]
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

Powered by blists - more mailing lists