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
prev parent 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