Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Message-ID: <6cfe6214-7b78-feca-e7ad-796a37ab369c@gmail.com>
Date:   Sun, 10 Oct 2021 19:45:50 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.1.2
Subject: Re: [net-next PATCH v5 06/14] net: dsa: qca8k: rework rgmii delay
 logic and scan for cpu port 6
Content-Language: en-US
To:     Ansuel Smith <ansuelsmth@gmail.com>, Andrew Lunn <andrew@lunn.ch>,
        Vivien Didelot <vivien.didelot@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Rob Herring <robh+dt@kernel.org>,
        Russell King <linux@armlinux.org.uk>, netdev@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20211011013024.569-1-ansuelsmth@gmail.com>
 <20211011013024.569-7-ansuelsmth@gmail.com>
From:   Florian Fainelli <f.fainelli@gmail.com>
In-Reply-To: <20211011013024.569-7-ansuelsmth@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


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@gmail.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