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:   Fri, 16 Apr 2021 09:12:26 +0200
From:   Thomas Bogendoerfer <tsbogend@...ha.franken.de>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 net-next 07/10] net: korina: Add support for device
 tree

On Fri, Apr 16, 2021 at 01:49:07AM +0200, Andrew Lunn wrote:
> > -	memcpy(dev->dev_addr, mac_addr, ETH_ALEN);
> > +	if (mac_addr) {
> > +		ether_addr_copy(dev->dev_addr, mac_addr);
> > +	} else {
> > +		u8 ofmac[ETH_ALEN];
> > +
> > +		if (of_get_mac_address(pdev->dev.of_node, ofmac) == 0)
> > +			ether_addr_copy(dev->dev_addr, ofmac);
> 
> You should be able to skip the ether_addr_copy() by passing 
> dev->dev_addr directly to of_get_mac_address().

good point

> 
> > +		else
> > +			eth_hw_addr_random(dev);
> > +	}
> >  
> >  	lp->rx_irq = platform_get_irq_byname(pdev, "korina_rx");
> >  	lp->tx_irq = platform_get_irq_byname(pdev, "korina_tx");
> > @@ -1146,8 +1157,21 @@ static int korina_remove(struct platform_device *pdev)
> >  	return 0;
> >  }
> >  
> > +#ifdef CONFIG_OF
> > +static const struct of_device_id korina_match[] = {
> > +	{
> > +		.compatible = "idt,3243x-emac",
> 
> You need to document this compatible somewhere under Documentation/devicetree/binding

checkpatch hinted to put it in an extra patch, it's patch 10 of this
series and looking at my inbox it didn't get through :-(.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ