All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.