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 devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel