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

[Joe Perches <joe@perches.com>]

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.