ar7: replace mac address parsing
PATCH 1/1 ar7: replace mac address parsing
Replace sscanf() with mac_pton().
---
arch/mips/ar7/platform.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-)
---
arch/mips/ar7/platform.c +1 -4
@@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) }if (mac) { -if (sscanf (mac,"%hhx:%hhx:%hhx:%hhx:%hhx:%hhx" , - &dev_addr[0 ], &dev_addr[1 ], - &dev_addr[2 ], &dev_addr[3 ], - &dev_addr[4 ], &dev_addr[5 ]) !=6 ) { +if (!mac_pton (mac, dev_addr)) {pr_warning ("cannot parse mac address, " "using random address\n" );eth_random_addr (dev_addr);
Quoted 1 line · Daniel Walter
Replace
sscanf()withmac_pton().
[]
arch/mips/ar7/platform.c
Quoted 1 line
arch/mips/ar7/platform.c +0
-0
[]
arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 310
Quoted 9 lines
arch/mips/ar7/platform.c +1
-4@@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) }if (mac) { -if (sscanf (mac,"%hhx:%hhx:%hhx:%hhx:%hhx:%hhx" , - &dev_addr[0 ], &dev_addr[1 ], - &dev_addr[2 ], &dev_addr[3 ], - &dev_addr[4 ], &dev_addr[5 ]) !=6 ) { +if (!mac_pton (mac, dev_addr)) {
There is a slight functional change with this conversion.
mac_pton is strict about leading 0's and requires a 17 char strlen.
sscanf will accept 0:1:2:3:4:5, mac_pton will not.
arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 312
Quoted 2 lines
arch/mips/ar7/platform.c +0
-0pr_warning ("cannot parse mac address, " "using random address\n" );
could be coalesced and pr_warn
pr_warn("cannot parse mac address - using random address\n");2014-06-24 8:48 GMT-07:00 Joe Perches <[email protected]>:
Quoted 17 lines · Daniel Walter
Quoted 1 line
Replace
sscanf()withmac_pton().[]
arch/mips/ar7/platform.c
Quoted 1 line
arch/mips/ar7/platform.c +0
-0[]
arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 310
Quoted 9 lines
arch/mips/ar7/platform.c +1
-4@@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) }if (mac) { -if (sscanf (mac,"%hhx:%hhx:%hhx:%hhx:%hhx:%hhx" , - &dev_addr[0 ], &dev_addr[1 ], - &dev_addr[2 ], &dev_addr[3 ], - &dev_addr[4 ], &dev_addr[5 ]) !=6 ) { +if (!mac_pton (mac, dev_addr)) {There is a slight functional change with this conversion.
Quoted 1 line
mac_ptonis strict about leading 0's and requires a 17 char strlen.
I do not have my devices handy, but I am fairly positive the use of sscanf() was exactly for that, we may or may not have leading zeroes. I am feeling a little uncomfortable with random code changes like that without being actually able to test on real hardware that has a variety of bootloaders and environment variables.
Quoted 12 lines
sscanf will accept 0:1:2:3:4:5,
mac_ptonwill not.arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 312
Quoted 2 lines
arch/mips/ar7/platform.c +0
-0pr_warning ("cannot parse mac address, " "using random address\n" );could be coalesced and
pr_warnpr_warn("cannot parse mac address - using random address\n");
Signature · 1 line
Florian
Quoted 18 lines · Florian Fainelli
2014-06-24 8:48 GMT-07:00 Joe Perches <[email protected]>:
Quoted 17 lines · Daniel Walter
Quoted 1 line
Replace
sscanf()withmac_pton().[]
arch/mips/ar7/platform.c
Quoted 1 line
arch/mips/ar7/platform.c +0
-0[]
arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 310
Quoted 9 lines
arch/mips/ar7/platform.c +1
-4@@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) }if (mac) { -if (sscanf (mac,"%hhx:%hhx:%hhx:%hhx:%hhx:%hhx" , - &dev_addr[0 ], &dev_addr[1 ], - &dev_addr[2 ], &dev_addr[3 ], - &dev_addr[4 ], &dev_addr[5 ]) !=6 ) { +if (!mac_pton (mac, dev_addr)) {There is a slight functional change with this conversion.
Quoted 7 lines
Quoted 1 line
mac_ptonis strict about leading 0's and requires a 17 char strlen.I do not have my devices handy, but I am fairly positive the use of
sscanf()was exactly for that, we may or may not have leading zeroes. I am feeling a little uncomfortable with random code changes like that without being actually able to test on real hardware that has a variety of bootloaders and environment variables.
One of my two devices has a mac address with one of the numbers being < 16, and it uses a fixed length mac:
(psbl) printenv
...HWA_0 00:16:B6:2A:A4:3B
Also looking at the history[1] of this code, it looks like this was just an optimization of an earlier code which did expect 17 char len:
for (i = 0; i < 6; i++)
dev_addr[i] = (char2hex(mac[i * 3]) << 4) +
char2hex(mac[i * 3 + 1]);So I'm tempted to say it should not cause any issues. But my sample size is rather small.
Regards
Jonas
[1] d16f7093b6eb4f3859856f6ee4ab504cbeeea0b9
Quoted 7 lines · Jonas Gorski
for (i = 0; i < 6; i++) dev_addr[i] = (char2hex(mac[i * 3]) << 4) + char2hex(mac[i * 3 + 1]);So I'm tempted to say it should not cause any issues. But my sample size is rather small.
4.1 is still long enough out to test ...
Ralf
Quoted 37 lines · Jonas Gorski
Quoted 18 lines · Florian Fainelli
2014-06-24 8:48 GMT-07:00 Joe Perches <[email protected]>:
Quoted 17 lines · Daniel Walter
Quoted 1 line
Replace
sscanf()withmac_pton().[]
arch/mips/ar7/platform.c
Quoted 1 line
arch/mips/ar7/platform.c +0
-0[]
arch/mips/ar7/platform.c static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) · line 310
Quoted 9 lines
arch/mips/ar7/platform.c +1
-4@@ -307,10 +307,7 @@ static void __init cpmac_get_mac(int instance, unsigned char *dev_addr) }if (mac) { -if (sscanf (mac,"%hhx:%hhx:%hhx:%hhx:%hhx:%hhx" , - &dev_addr[0 ], &dev_addr[1 ], - &dev_addr[2 ], &dev_addr[3 ], - &dev_addr[4 ], &dev_addr[5 ]) !=6 ) { +if (!mac_pton (mac, dev_addr)) {There is a slight functional change with this conversion.
Quoted 7 lines
Quoted 1 line
mac_ptonis strict about leading 0's and requires a 17 char strlen.I do not have my devices handy, but I am fairly positive the use of
sscanf()was exactly for that, we may or may not have leading zeroes. I am feeling a little uncomfortable with random code changes like that without being actually able to test on real hardware that has a variety of bootloaders and environment variables.One of my two devices has a mac address with one of the numbers being < 16, and it uses a fixed length mac:
(psbl) printenv
...HWA_000:16:B6:2A:A4:3BAlso looking at the history[1] of this code, it looks like this was just an optimization of an earlier code which did expect 17 char len:
Quoted 8 lines
for (i = 0; i < 6; i++) dev_addr[i] = (char2hex(mac[i * 3]) << 4) + char2hex(mac[i * 3 + 1]);So I'm tempted to say it should not cause any issues. But my sample size is rather small.
[1]d16f7093b6eb4f3859856f6ee4ab504cbeeea0b9
Wow Jonas, a 9 month thread gestation...
Given the old code and the commit comment, I'd say it was almost certainly safe and my issue with the patch resolved.