On 10.05.2015 00:29, Joe Perches wrote:
> On Sat, 2015-05-09 at 23:18 +0200, Mateusz Kulikowski wrote:
>> Add __aligned(2) into ethernet addresses allocated on stack or in non-packed
>> structures. Use ETH_ALEN as array length in places where it was hardcoded to
>> 6.
> []
>> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
>> b/drivers/staging/rtl8192e/rtl8192e/r8192E_dev.c
> []
>> @@ -321,7 +321,8 @@ static void rtl8192_read_eeprom_info(struct net_device
>> *dev)
>> u8 ICVer8192, ICVer8256;
>> u16 i, usValue, IC_Version;
>> u16 EEPROMId;
>> - u8 bMac_Tmp_Addr[6] = {0x00, 0xe0, 0x4c, 0x00, 0x00, 0x01};
>> + u8 bMac_Tmp_Addr[ETH_ALEN] __aligned(2) = {0x00, 0xe0, 0x4c,
>> + 0x00, 0x00, 0x01};
>
> While this is safe, as this follows a u16, it's unnecessary.
>
> Also, ideally, this would be
> u8 foo[ETH_ALEN] = {
> 1, 2, 3, 4, 5, 6
> };
> or just left on a single line.
I put __aligned to most places to show authors intention and to prevent someone
from breaking it by
(for example) removing u16 above due some refactoring.
If you insist - I will remove it.
>
>> diff --git a/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
>> b/drivers/staging/rtl8192e/rtl8192e/rtl_core.c
> []
>> @@ -2573,8 +2573,9 @@ static int rtl8192_ioctl(struct net_device *dev,
>> struct ifreq *rq, int cmd)
>> int ret = -1;
>> struct rtllib_device *ieee = priv->rtllib;
>> u32 key[4];
>> - u8 broadcast_addr[6] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
>> - u8 zero_addr[6] = {0};
>> + u8 broadcast_addr[ETH_ALEN] __aligned(2) = {0xff, 0xff, 0xff,
>> + 0xff, 0xff, 0xff};
>> + u8 zero_addr[ETH_ALEN] __aligned(2) = {0};
>
> If these are used only in tests, these are probably better
> being removed and using is_<foo>_ether_addr or maybe
> if these used in things other than tests, being converted
> to static const so they are not reinitialized on each
> call of the function.
>
zero_addr in fact is used only for comparison - I'll use is_eth_zero_addr;
broadcast is used as parameter so will make it static const (and update used
functions to accept const ethaddr)
Regards,
Mateusz
_______________________________________________
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
