Date: Wed, 09 Mar 2016 12:22:10 -0500 (EST)
Message-Id: <20160309.122210.1419008371671612631.davem@davemloft.net>
To: michal.simek@xilinx.com
Cc: nicolas.ferre@atmel.com, moritz.fischer@ettus.com,
        cyrille.pitchen@atmel.com, punnaia@xilinx.com, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/3] net: macb: Fix coding style issues
From: David Miller <davem@davemloft.net>
In-Reply-To: <56E04F73.6030504@xilinx.com>
References: <1457367460-9123-1-git-send-email-moritz.fischer@ettus.com>
	<56DDB6CA.8000100@atmel.com>
	<56E04F73.6030504@xilinx.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1400
Lines: 38

From: Michal Simek <michal.simek@xilinx.com>
Date: Wed, 9 Mar 2016 17:29:39 +0100

> On 7.3.2016 18:13, Nicolas Ferre wrote:
>> Le 07/03/2016 17:17, Moritz Fischer a ?crit :
>>> Hi Nicolas,
>>>
>>> this series deals with most of the checkpatch warnings
>>> generated for macb. There are two BUG_ON()'s that I didn't touch, yet,
>>> that were suggested by checkpatch, that I can address in a follow up
>>> commit if needed.
>>> Let me know if you want me to split the fixes differently or squash
>>> them into one commit.
>> 
>> Hi,
>> 
>> I'm not usually fond of this type of patches, but I must admit that this
>> series corrects some style issues.
>> 
>> So, I would like more feedback from Michal and Cyrille as these changes
>> may delay some of the not-merged-yet features or more important
>> work-in-progress on their side.
>> 
>> On the other hand, if we all think it's a calm period for this macb
>> driver, we may find interesting to merge some "cleanup and style"
>> enhancements.
> 
> Not a problem with merging cleanups in general. We have several out of
> tree patches but doesn't make sense to to wait.
> I wasn't in cc for the series but I don't like this change to be the
> part of cleanup series.
> 
> 	mac = of_get_mac_address(np);
>  	if (mac)
> -		memcpy(bp->dev->dev_addr, mac, ETH_ALEN);
> +		ether_addr_copy(bp->dev->dev_addr, mac);

Why?  This is what we tell people to use.