Messages in this thread | | | Subject | Re: [PATCH v3 3/4] staging: rtl8723bs: use ether_addr_copy() in rtw_macaddr_cfg() | From | Michael Straube <> | Date | Wed, 27 Jun 2018 14:56:00 +0200 |
| |
Am 27.06.2018 um 10:33 schrieb Dan Carpenter: > On Tue, Jun 26, 2018 at 10:32:09PM +0200, Michael Straube wrote: >> >> On 06/26/18 22:17, Joe Perches wrote: >>> On Tue, 2018-06-26 at 21:44 +0200, Michael Straube wrote: >>>> On 06/26/18 19:32, Andy Shevchenko wrote: >>>>> On Tue, Jun 26, 2018 at 11:14 AM, Michael Straube >>>>> <straube.linux@gmail.com> wrote: >>>>>> Use ether_addr_copy() instead of memcpy() to copy the mac address. >>>>>> >>>>> >>>>> Suggested-by ? >>>>> >>>> >>>> I'll add it. Sorry, I was not aware of the Suggested-by tag. >>>> >>>>> Btw, ensure that the source and destination buffers are aligned to u16 >>>>> as required by API. >>>> >>>> To be honest I'm not sure how to do that excactly. >>>> >>>> Use __align(2) in the array declarations? e.g.: >>>> >>>> u8 mac[ETH_ALEN] __align(2); >>> >>> All initial function automatics are naturally aligned. >>>> >> So there is nothing to change? Now I'm confused. > > Do not add the __align(2), as Joe says, it's not required. You just > need to C alignment rules (it's expected/required for this sort of > patch). > > Like if you have a struct: > > struct foo { > char a; > int b; > }; > > There is going to be a 3 byte gap between a and b because ints are > normally __align(4). The exception is when the struct is __packed. So > sizeof(struct foo) in this case is going to be 8. kmalloc() returns > pointers which are 8 at least byte aligned normally. See > ARCH_KMALLOC_MINALIGN. There is one arch where it's 4 byte aligned? > > So when you would get things which aren't __align(2) is when you have: > > struct bar { > char a[3]; > u8 mac[ETH_ALEN]; > }; > > Here the struct member before the mac[] is an odd number of char. Or > when the struct is packed. > > regards, > dan carpenter >
Thank you for your explanation. I will not add __aligned(2). The other buffer is u32 aligned:
struct eeprom_priv { u8 bautoload_fail_flag; u8 bloadfile_fail_flag; u8 bloadmac_fail_flag; u8 EepromOrEfuse;
u8 mac_addr[6]; /* PermanentAddress */
...
u32 ocr;
... };
Should I add a thanks line to the commit message:
Thanks to Dan Carpenter, Joe Perches and Andy Shevchenko.
Or would that be considered as too much?
Regards Michael
| |