From: Martin Blumenstingl <[email protected]>
Print the port which is not found to be part of a bridge so it's easier
to investigate the underlying issue.
Signed-off-by: Martin Blumenstingl <[email protected]>
---
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;
}
--
2.39.2
On Thu, Jun 06, 2024 at 10:52:34AM +0200, Martin Schiller wrote:
> From: Martin Blumenstingl <[email protected]>
>
> 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 <[email protected]>
> ---
> 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.
On 2024-06-07 13:41, Vladimir Oltean wrote:
> On Thu, Jun 06, 2024 at 10:52:34AM +0200, Martin Schiller wrote:
>> From: Martin Blumenstingl <[email protected]>
>>
>> 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?
Well, there are probably still several problems with this driver. Martin
Blumenstingl is probably referring to the problem discussed in [1] and
[2].
[1] https://github.com/openwrt/openwrt/pull/13200
[2] https://github.com/openwrt/openwrt/pull/13638
>
>> Signed-off-by: Martin Blumenstingl
>> <[email protected]>
>> ---
>> 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.
Yes, you are right. I'll change that.
On Fri, Jun 07, 2024 at 03:51:19PM +0200, Martin Schiller wrote:
> On 2024-06-07 13:41, Vladimir Oltean wrote:
> > On Thu, Jun 06, 2024 at 10:52:34AM +0200, Martin Schiller wrote:
> > > From: Martin Blumenstingl <[email protected]>
> > >
> > > 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?
>
> Well, there are probably still several problems with this driver. Martin
> Blumenstingl is probably referring to the problem discussed in [1] and [2].
>
> [1] https://github.com/openwrt/openwrt/pull/13200
> [2] https://github.com/openwrt/openwrt/pull/13638
Ok, but that doesn't technically exercise this error path.