lkml.org 
[lkml]   [2018]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v3 3/4] staging: rtl8723bs: use ether_addr_copy() in rtw_macaddr_cfg()
From
Date
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


\
 
 \ /
  Last update: 2018-06-27 14:56    [W:0.497 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site