linux-kernel - Re: [PATCH 0/3] net: macb: Fix coding style issues

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, 09 Mar 2016 15:26:41 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	michal.simek@...inx.com
Cc:	nicolas.ferre@...el.com, moritz.fischer@...us.com,
	cyrille.pitchen@...el.com, punnaia@...inx.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/3] net: macb: Fix coding style issues

From: Michal Simek <michal.simek@...inx.com>
Date: Wed, 9 Mar 2016 18:29:01 +0100

> On 9.3.2016 18:22, David Miller wrote:
>> From: Michal Simek <michal.simek@...inx.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.
> 
> I would expect this as separate patch not the part of one huge cleanup
> patch which does just comment and space cleanups.

That is true.