public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Jerry Van Baren <gvb.uboot@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH v2] fdt: rework fdt_fixup_ethernet() to use env instead of bd_t
Date: Mon, 18 Aug 2008 19:53:22 -0400	[thread overview]
Message-ID: <48AA0B72.6020300@gmail.com> (raw)
In-Reply-To: <20080818205413.E48C2243AB@gemini.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

      reply	other threads:[~2008-08-18 23:53 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18 19:23 [U-Boot] [PATCH v2] fdt: rework fdt_fixup_ethernet() to use env instead of bd_t Kumar Gala
2008-08-18 19:30 ` Wolfgang Denk
2008-08-18 19:40   ` Kumar Gala
2008-08-18 19:49     ` Scott Wood
2008-08-18 19:57       ` Kumar Gala
2008-08-18 20:55         ` Wolfgang Denk
2008-08-18 21:04           ` Kumar Gala
2008-08-18 20:54     ` Wolfgang Denk
2008-08-18 23:53       ` Jerry Van Baren [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48AA0B72.6020300@gmail.com \
    --to=gvb.uboot@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox