Received-SPF: pass (google.com: domain of linux-kernel+bounces-205938-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Fri, 7 Jun 2024 14:41:44 +0300
From: Vladimir Oltean <olteanv@gmail.com>
To: Martin Schiller <ms@dev.tdt.de>
Cc: martin.blumenstingl@googlemail.com, hauke@hauke-m.de, andrew@lunn.ch,
	f.fainelli@gmail.com, davem@davemloft.net, edumazet@google.com,
	kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org, netdev@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next 13/13] net: dsa: lantiq_gswip: Improve error
 message in gswip_port_fdb()
Message-ID: <20240607114144.knza5aapic2j5txu@skbuf>
References: <20240606085234.565551-1-ms@dev.tdt.de>
 <20240606085234.565551-14-ms@dev.tdt.de>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240606085234.565551-14-ms@dev.tdt.de>

On Thu, Jun 06, 2024 at 10:52:34AM +0200, Martin Schiller wrote:
> From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> 
> Print the port which is not found to be part of a bridge so it's easier
> to investigate the underlying issue.

Was there an actual issue which was investigated here? More details?

> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> ---
>  drivers/net/dsa/lantiq_gswip.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
> index 4bb894e75b81..69035598e8a4 100644
> --- a/drivers/net/dsa/lantiq_gswip.c
> +++ b/drivers/net/dsa/lantiq_gswip.c
> @@ -1377,7 +1377,8 @@ static int gswip_port_fdb(struct dsa_switch *ds, int port,
>  	}
>  
>  	if (fid == -1) {
> -		dev_err(priv->dev, "Port not part of a bridge\n");
> +		dev_err(priv->dev,
> +			"Port %d is not known to be part of bridge\n", port);
>  		return -EINVAL;
>  	}

Actually I would argue this is entirely confusing. There is an earlier
check:

	if (!bridge)
		return -EINVAL;

which did _not_ trigger if we're executing this. So the port _is_ a part
of a bridge. Just say that no FID is found for bridge %s (bridge->name),
which technically _is_ what happened.