From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ben Warren Date: Tue, 10 Feb 2009 21:45:05 -0800 Subject: [U-Boot] [PATCH 01/27 v2] Blackfin: bfin_mac: force board_get_enetaddr() usage In-Reply-To: <200902101536.37531.vapier@gentoo.org> References: <49814203.7020604@gmail.com> <20090203081627.9DE518322908@gemini.denx.de> <200902031440.01665.vapier@gentoo.org> <200902101536.37531.vapier@gentoo.org> Message-ID: <499265E1.4050903@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Mike Frysinger wrote: > On Tuesday 03 February 2009 14:40:00 Mike Frysinger wrote: > >> i think we can agree that this does not scale at all. if, however, we >> change the global data to something like: >> typedef struct bd_info { >> ... >> #ifdef CONFIG_NET_MULTI >> uchar bi_enetXaddr[CONFIG_NET_MULTI_MAX][6]; >> # define bi_enetaddr bi_enetXaddr[0] >> #else >> uchar bi_enetaddr[6]; >> #endif >> ... >> }; >> > > Ben: does this sound reasonable ? if so, i can start a patch series moving in > this direction ... > -mike > Thanks for tackling this cluster$%@#. I'm not crazy about the CONFIG_NET_MULTI_MAX, but then I'm not really sure why the ethernet addresses exist in global data on boards with CONFIG_NET_MULTI. The net library doesn't use them, most (maybe all?) of the drivers don't look at it. Some common code does, but does it need to? Maybe it's needed to pass to some operating systems? This is an example of something that could use some serious refactoring, but I expect it's an onion with many, many layers. OTOH, if you're going to change the name of a variable in global data, you'll find out really fast where it's used. Maybe we can gut it completely? I'm lacking in historical perspective and my world view is pretty limited, so hopefully others (read WD) will chime in. regards, Ben