Re: [PATCH -next 2/2] staging: r8188eu: use eth_broadcast_addr() to assign broadcast address

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021/6/9 1:34, Joe Perches wrote:
> On Tue, 2021-06-08 at 19:01 +0200, Greg Kroah-Hartman wrote:
>> On Tue, Jun 08, 2021 at 09:45:49AM -0700, Joe Perches wrote:
>>> On Tue, 2021-06-08 at 16:12 +0200, Greg Kroah-Hartman wrote:
>>>> On Tue, Jun 08, 2021 at 10:16:20PM +0800, Liu Shixin wrote:
>>>>> Use eth_broadcast_addr() to assign broadcast address.
>>>> That says what you do, but not _why_ you are doing this?
>>>>
>>>> Why make this change?  What benifit does it provide?
>>> The commit message is clear and concise as using available kernel
>>> mechanisms is better than homegrown or duplicative ones.
>>>
>>> Are you asking merely becuse Liu Shixin hasn't had many staging
>>> commits?
>> I'm asking because this changelog text does not explain why this is
>> needed at all and needs to be changed to do so.
> IYO.
>
> IMO it's obvious and fine as is and you are asking for overly
> fine-grained analyses in commit messages.
>
> The subject is clear though the commit message is merely duplicative.
>
> It _could_ show the reduction in object size for some versions of gcc.
>
> $ size drivers/staging/rtl8188eu/core/rtw_mlme_ext.o*
>    text	   data	    bss	    dec	    hex	filename
>   53259	    372	   2430	  56061	   dafd	drivers/staging/rtl8188eu/core/rtw_mlme_ext.o.gcc6.new
>   53355	    372	   2430	  56157	   db5d	drivers/staging/rtl8188eu/core/rtw_mlme_ext.o.gcc6.old
>   54673	    372	   2430	  57475	   e083	drivers/staging/rtl8188eu/core/rtw_mlme_ext.o.gcc10.new
>   54673	    372	   2430	  57475	   e083	drivers/staging/rtl8188eu/core/rtw_mlme_ext.o.gcc10.old
>
> It _could_ describe how the kernel mechanisms depend on a minimum
> alignment of __aligned(2) in the tested address and also show that
> the address is properly minimum aligned.
>
> struct ieee80211_hdr {
> 	__le16 frame_control;
> 	__le16 duration_id;
> 	u8 addr1[ETH_ALEN];
> 	u8 addr2[ETH_ALEN];
> 	u8 addr3[ETH_ALEN];
> 	__le16 seq_ctrl;
> 	u8 addr4[ETH_ALEN];
> } __packed __aligned(2);
> [...]
> 	struct ieee80211_hdr *pwlanhdr;
> [...]
> -	ether_addr_copy(pwlanhdr->addr1, bc_addr);
> +	eth_broadcast_addr(pwlanhdr->addr1);
>
> It _could_ show that the commit has some effect on runtime.
> It _could_ show that it passes some (unavailable) regression test.
>
> IMO: None of those are really necessary here.
>
>
> .
>
The variable bc_addr is repeated many times in the code and looks like magic number. I want to simplify the code by remoing unnecessary bc_addr.
And I think it's better using eth_broadcast_addr() directly rather than using ether_addr_copy() + bc_addr.

Thanks to Joe for the data.

Thanks,






[Index of Archives]     [Linux Driver Development]     [Linux Driver Backports]     [DMA Engine]     [Linux GPIO]     [Linux SPI]     [Video for Linux]     [Linux USB Devel]     [Linux Coverity]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux