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] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Jun 2024 13:45:26 +0200
From: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
To: Jakub Kicinski <kuba@...nel.org>
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

Hi Jakub,

Thanks for your review.

I will address all comments. I had already posted a v7 of this prior to 
your comments addressing a silly build issue I failed to catch. I have 
mark v7 as change requested in patchwork.

I do have one question.

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?

-- 
Kind Regards,
Niklas Söderlund

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ