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.li...@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
