From mboxrd@z Thu Jan 1 00:00:00 1970 From: Detlev Zundel Date: Tue, 30 Mar 2010 11:42:08 +0200 Subject: [U-Boot] net, kirkwood_egiga: init mac address before using network commands In-Reply-To: <20100330110158.53b0d595@marrow.netinsight.se> (Simon Kagstrom's message of "Tue, 30 Mar 2010 11:01:58 +0200") References: <4BB18E5F.6060705@denx.de> <20100330100127.5f36495c@marrow.netinsight.se> <20100330082659.36ECFE73028@gemini.denx.de> <20100330110158.53b0d595@marrow.netinsight.se> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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