Hi Wolfgang,
I cannot understand how you might think that writing some data to registers or internal RAM of a device could be NOT considered as "touching" this device. You modify the state of this device, ergo you are touching it. Or not?
This is getting philosophical, really and I can find good arguments for both views: If you consider the mac sram cells to be part of the state of the device, you _do_ change the state. On the other hand, the ethernet controller ip block very likely has no idea whatsoever if those sram was touched, so in this view you _do not_ change the state.
This argument takes you from bad to worse. If you consider this SRAM as a separate device (not related to the Ethernet), then the "Initialize devices only when they are needed within U-Boot" rule still means that this SRAM device shall not be touched, as we don't need or use it in U-Boot (unless running some network command).
You are regarding 6 bytes of SRAM as a device _only so you can mechanically apply a sentence to it_ which may loose its meaning in the process? You loose me down this route, sorry.
There was this quote on this mailing list previously so maybe it is time to repost it:
A foolish consistency is the hobgoblin of little minds. -- Ralph Waldo Emerson
So if this is getting philosophical, why not ask the question "under what circumstances could this writing into sram have negative effects?". I for myself cannot find any point to raise here.
With this approach we can probably partially initialize a number of other devices as well.
This is only if you accept that writing 6 bytes of SRAM is "partly initializing a device", which I do not follow, sorry.
But does it make sense? Shall we start to accept code that will perform the "fast" part of initialization for a random collection of devices? Leaving devices in a "half-initialized" state?
Again, I do not agree on the "half-initialized state".
As I see it, the core problem is a gap loophole in the (ARM) Linux kernel interface. If we had - for example - device tree support for ARM, or something like a MAC ATAG, all this discussion would be void.
Do you agree?
Not quite. I know that this topic crept up on ARM, but actually it was also the netdev mailing list that turned down the attempts to allow for mac addresses to be passed to the network drivers. So this is not bounded to ARM.
I would rather restate it in the light of "what initializations are to be done by the firmware and what initializations are to be done by the linux drivers".
Now this is a controversial thing, for sure, but it is all the more worthy of real reflection instead of blindly applying rules.
So why cannot you simply concede that we are knowingly violating our own rules and take the line of least resistance?
Why should I? I still do not believe that following a sentence blindly is one of our rules, sorry. If this is what you think, then say so clearly and we can let the discussion rest as then there is no room for discussion in the first place.
I also tried for quite a length to explain why I also consider this not a "least resistance" way - no matter how often you repeat it.
Yes, it solves a problem. Also it is a static initialization which I feel is something the bootloader should do. U-Boot knows ethaddr, so again I see no negative, only positive consequences of doing such a thing
It is a violation of the design rule, still. We don't make any difference there between "static" or "dynamic", "fast" or "slow" initializations. I think it is good that we don't.
For myself I disagree. I do not consider switching off thought to be a good thing.
If you re-read my previous postings in this thread you might even see that I tend to take a pretty pragmatic position here and support the suggested fix for the exiting (obviously incorrect) behaviour.
So it seems I did not understand your "please include in your fix" statement. Can you tell me exactly what you meant by this?
I was referring to this part of Heikos mail:
While writing this, and realizing that this behaviour is a feature, maybe this problem occur on other network drivers on arm plattforms too ... hah, found one:
drivers/net/kirkwood_egiga.c
did it in the same way as drivers/net/fec_mxc.c ... Ok, it is in line with uboot standard, but arm plattforms which booting linux without doing network trafic under uboot tend to have different mac addresses ...
This should be solved!
The "Please include in your fix" means that the same bug fix as implemented for the fec_mxc driver should also be applied to the kirkwood_egiga driver - I see no sense in knowing the same bug is in two files and fixing it in just one.
We are drifing apart even more. I do not say that I grasp every part of the kirkwood_egiga driver, but for me it seems like it only reads the ethaddr environment addresses which I fail to see why it does that. What I cannot see is that it programs the mac address in any way. So what exactly is the bug you are referring to here and how do you "support a pragmatic fix"?
Cheers Detlev