From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Mon, 18 Aug 2008 19:53:22 -0400 Subject: [U-Boot] [PATCH v2] fdt: rework fdt_fixup_ethernet() to use env instead of bd_t In-Reply-To: <20080818205413.E48C2243AB@gemini.denx.de> References: <20080818193004.145DE24899@gemini.denx.de> <119C6E28-E979-4B97-87AD-9603CD5FFDAA@kernel.crashing.org> <20080818205413.E48C2243AB@gemini.denx.de> Message-ID: <48AA0B72.6020300@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 Wolfgang Denk wrote: > Dear Kumar Gala, > > In message <119C6E28-E979-4B97-87AD-9603CD5FFDAA@kernel.crashing.org> you wrote: >>>> This makes the code a bit more flexible to the number of ethernet >>>> interfaces. Right now we assume a max of 10 interfaces. >>> Hm... where exactly is this artificial limit coming from? Do we really >>> need it? >> We need some upper limit to stop checking at. > > The upper limit should be the real (configured) number of network > interfaces, not some artificial limit which is either too high or too > low. It is (was) - CFG_MAX_NUM_ETH: + for (i = 0; i < CFG_MAX_NUM_ETH; i++) { Actually, I don't see any arbitrary upper limit in the code, including Kumar's value of 10 (well, until you overflow the strings, anyway, but that is 100 interfaces). >>> If we assume, that all existing interfaces must have addresses >>> assigned, we could use a "break" here instead of the "continue". That >>> would be (1) much faster on most boards and (2) would allow us to get >>> rid of the artifical limit of 10. CFG_MAX_NUM_ETH would presumably be the physical max and the /aliases/ethernet (and associated env variables) should *not* be sparse, therefore I agree with the the "break" recommendation. >>> What do you think? >> I dont like making this assumption and do think its too much work to >> check 10 possible aliases and skip to the next one if it doesn't exist. > > I do not want to see any such hard-coded limits if they can be > avoided. Which problem do you see to stop here at the first interface > that has no MAC address assigned to it? I originally wrote to support sparse ethernet MAC addresses, but on reflection I don't think that is an issue because we will have /aliases/ethernet[0-9]+ which won't be sparse, even if the actual SOC (e.g. PowerQuicc) channels that are used for ethernet are used in a sparse manner. > Best regards, > > Wolfgang Denk Best regards, gvb