I believe I have found a critical bug in the smsc75xx driver and would like to
know the right way to proceed.
Problem:
1. Environment:
- Multiple hard-wired SMSC LAN7500 devices connected at boot time and never
removed (not removable, in my case).
- Tested under the following Ubuntu ARM-based systems:
PandaBoard ES: Linux Panda-216 3.5.0-215-omap4 #22-Ubuntu SMP PREEMPT
Mon Nov 19 16:41:38 UTC 2012 armv7l armv7l armv7l GNU/Linux
Variscite OM44 DVK: Linux OM44-134 3.4.0-1487-omap4 #6+var5 SMP PREEMPT
Mon Oct 15 19:18:50 IST 2012 armv7l armv7l armv7l GNU/Linux
Custom OM44-based system: Linux OM44-120 3.4.0-1487-omap4 #6+var7 SMP
PREEMPT Sun Oct 28 11:51:16 IST 2012 armv7l armv7l armv7l GNU/Linux
2. Observations:
- Expected behavior: A random MAC address is assigned at system start.
- Unexpected behavior: Doing "ifconfig ethX down; ifconfig ethX up" always
forces a new random MAC address to be assigned.
- Unexpected behavior: All attempts to manually assign a MAC address are
consistently overwritten by a subsequent "ifconfig ethX up".
3. Desired behavior:
- I would like to be able to assign desired MAC addresses to any number of
attached smsc75xx devices that will persist across any number of ifconfig
up/down cycles.
4. Work-arounds:
- None found. All attempts to manually configure a MAC address (including
bootargs) are stepped on by "ifconfig ethX up".
5. Planned hack:
- Modify smsc75xx.c to remove code that sets the random MAC address: If the
device does not initialize with a valid MAC address from EEPROM, force the
interface to fail until a valid MAC address is (manually) assigned (e.g. by
bootargs, custom init scripts, ifconfig, macchanger, etc.).
I'm in no way a kernel or USB or device driver hacker (or even much of a C
programmer since my Python religious conversion), so this will be a blind hack
that should never be allowed anywhere near the source tree. I haven't even
built a kernel or module in 5 years (due to increasingly wonderful vendor and
distribution support), so this will be an excruciatingly slow process
(self-hosted on an embedded system with only SD storage). Advice from true
experts would be massively appreciated.
5. Going Forward:
- What is the "most correct" path to a permanent fix for this bug?
- Are there known-good work-arounds I haven't yet found?
- What more should I do bring needed attention to this bug beyond this report
to this list?
TIA,
-BobC
