Calling a switchdev notifier encodes additional information into the
return code. Using this value directly makes error messages confusing.

Use notifer_to_errno() to restore the original errno value.

Fixes: 830763b96720 ("net: dsa: mv88e6xxx: mac-auth/MAB implementation")
Signed-off-by: Elliot Ayrey <elliot.ayrey@alliedtelesis.co.nz>
---
 drivers/net/dsa/mv88e6xxx/switchdev.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/dsa/mv88e6xxx/switchdev.c b/drivers/net/dsa/mv88e6xxx/switchdev.c
index 4c346a884fb2..7c59eca0270d 100644
--- a/drivers/net/dsa/mv88e6xxx/switchdev.c
+++ b/drivers/net/dsa/mv88e6xxx/switchdev.c
@@ -79,5 +79,5 @@ int mv88e6xxx_handle_miss_violation(struct mv88e6xxx_chip *chip, int port,
 				       brport, &info.info, NULL);
 	rtnl_unlock();
 
-	return err;
+	return notifier_to_errno(err);
 }

On Tue, Dec 17, 2024 at 05:39:30PM +1300, Elliot Ayrey wrote:
> Calling a switchdev notifier encodes additional information into the
> return code. Using this value directly makes error messages confusing.
> 
> Use notifer_to_errno() to restore the original errno value.
> 
> Fixes: 830763b96720 ("net: dsa: mv88e6xxx: mac-auth/MAB implementation")
> Signed-off-by: Elliot Ayrey <elliot.ayrey@alliedtelesis.co.nz>
> ---
>  drivers/net/dsa/mv88e6xxx/switchdev.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/dsa/mv88e6xxx/switchdev.c b/drivers/net/dsa/mv88e6xxx/switchdev.c
> index 4c346a884fb2..7c59eca0270d 100644
> --- a/drivers/net/dsa/mv88e6xxx/switchdev.c
> +++ b/drivers/net/dsa/mv88e6xxx/switchdev.c
> @@ -79,5 +79,5 @@ int mv88e6xxx_handle_miss_violation(struct mv88e6xxx_chip *chip, int port,
>  				       brport, &info.info, NULL);
>  	rtnl_unlock();
>  
> -	return err;
> +	return notifier_to_errno(err);

I just had a quick look at other users of call_switchdev_notifiers()
and all but vxlan_core.c and this one discarded the return
value. Would that be a better fix, making the code more uniform?

	Andrew

On Tue, 2024-12-17 at 10:54 +0100, Andrew Lunn wrote:
> I just had a quick look at other users of call_switchdev_notifiers()
> and all but vxlan_core.c and this one discarded the return
> value. Would that be a better fix, making the code more uniform?
> 
> 	Andrew

Hi Andrew, I am hesitant to remove this error as it was very helpful
during development and helped to diagnose some subtle issues that would
have otherwise been very hard to notice.

On Sun, Jan 26, 2025 at 10:07:26PM +0000, Elliot Ayrey wrote:
> On Tue, 2024-12-17 at 10:54 +0100, Andrew Lunn wrote:
> > I just had a quick look at other users of call_switchdev_notifiers()
> > and all but vxlan_core.c and this one discarded the return
> > value. Would that be a better fix, making the code more uniform?
> > 
> > 	Andrew
> 
> Hi Andrew, I am hesitant to remove this error as it was very helpful
> during development and helped to diagnose some subtle issues that would
> have otherwise been very hard to notice.

Can you give more details about how you encountered this issue?
One could similarly argue that a call_switchdev_notifiers() error was
ignored until now, and maybe the system still did something reasonable
and thus, properly handling the error now risks introducing a regression
for them. No way to really know except if the commit author (you) makes
a reasonable analysis in the commit message leading to the conclusion
that the patch is worthy of backporting to stable kernels (i.e. fixes a
user-visible incorrect behavior).