netdev - Re: [net-next,v6] net: ethernet: rtsn: Add support for Renesas Ethernet-TSN

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] [day] [month] [year] [list]

Date: Wed, 12 Jun 2024 14:47:32 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Niklas Söderlund
 <niklas.soderlund+renesas@...natech.se>
Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org,
 linux-renesas-soc@...r.kernel.org
Subject: Re: [net-next,v6] net: ethernet: rtsn: Add support for Renesas
 Ethernet-TSN

On Wed, 12 Jun 2024 13:45:26 +0200 Niklas Söderlund wrote:
> On 2024-06-11 19:56:16 -0700, Jakub Kicinski wrote:
> > > +	netdev_info(ndev, "MAC address %pM\n", ndev->dev_addr);  
> > 
> > That's fairly unusual, why print the MAC address to logs?  
> 
> Renesas net drivers print the MAC address in probe,
> 
> * RAVB
> 
>     netdev_info(ndev, "Base address at %#x, %pM, IRQ %d.\n",
>             (u32)ndev->base_addr, ndev->dev_addr, ndev->irq);
> 
> * SH_ETH
> 
>     netdev_info(ndev, "Base address at 0x%x, %pM, IRQ %d.\n",
>             (u32)ndev->base_addr, ndev->dev_addr, ndev->irq);
> 
> * RENESAS_ETHER_SWITCH
> 
>     rswitch_for_each_enabled_port(priv, i) 
>     	netdev_info(priv->rdev[i]->ndev, "MAC address %pM\n",
> 		priv->rdev[i]->ndev->dev_addr);
> 
> I have no strong opinion on if this is good or bad, but I do think they 
> all shall behave the same. What do you think is the best way forward, 
> keep this behavior in this new RTSN driver or remove the print from the 
> old drivers?

I had a hunch this may be the case :) People invent local customs for
this sort of "hello" messages in driver probe. Developers consider it
useful because when you get logs from a user you can tell whether
driver got probed or not immediately. But there's no agreed upon
convention across networking drivers, and if we need to debug probing -
the device driver core should be put to task to output more
comprehensive information generically.

Anyway, weak preference for removing the print, but no big deal.