[U-Boot] net, kirkwood_egiga: init mac address before using network commands

[Detlev Zundel]

Hi Simon,

>> Interesting.  Why would you do this?  Why would you not rather fix the
>> Linux driver instead? [This is what I would do.]
>
> Basically two reasons: First, it's a simpler fix in U-boot (a oneliner
> for Kirkwood), and secondly because (as far as I understand, correct me
> if I'm wrong), it lacks any well-defined protocol to transfer this
> knowledge to the kernel driver.

Yes, this is one reason, which will be fixed once the device tree is
available (for the boards using it, device tree on ARM in the
foreseeable future will only be optional, not mandatory).  But this is
not the only reason for me personally.

> I know mostly how it looks on the OpenRD board, where the MAC address
> is stored in the U-boot environment. Easy to access in U-boot, but a
> lot trickier from Linux. Sure, you could transfer it via a command-line
> parameter or something, but personally I think this is uglier than
> setting it up in U-boot anyway.

This is the other reason for me indeed.  For the current problem at
hand, we would need to extend the protocol, the protocol handlers and
the linux drivers in order to pass 6 bytes into Linux which then get
simply programmed into registers.  Why not regard the MAC registers as
the protocol to pass this information to the linux driver?  This already
exists and needs no further change whatsoever.

Moreover, linux drivers do not initialize _everything_ for the devices
they use, not even in PowerPC world.  Take for example the GPIOs on a
5200 board.  They are configured by this (admittedly inelegant) central
portconfig register.  The linux drivers accessing pins (which can be
either gpios or function pins) do not touch this portconfig but rely on
its correct setting in U-Boot.  So for the 5200 boards in U-Boot, we set
this portconfig in U-Boot even though we may never touch any of the
devices this "configuration" touches.  This is just one example I'm
personally aware of, I'm sure one can find many more like this.

Of course we can surely extend the device tree with yet more
information, but in my personal view it is also perfectly fine to
delegate some taks to the firmware.  We only have to be clear about what
tasks are to be done by firmware and what the operating system will do
by itself.

In the long run I think that if we extend all linux drivers to be
capable to initialize everything about their context, we have an
unmaintainable mess in the linux drivers.  I'd rather like to see linux
drivers implement the shared functionality and firmware to setup a
context of bare usability.

So the cut between what firmware can and/or should initialize is not
always as black and white for me personally but still an important
question to discuss.

Cheers
  Detlev

-- 
Music scenes ain't real life / They won't get rid of the bomb
Won't eliminate rape / Or bring down the banks / any kind of change
Takes more time and work / than changing channels on a TV set
                                        -- Jello Biafra
--
DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: dzu at denx.de