public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Daniel Mack <daniel@caiaq.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] ne2000: take MAC address from config if	available
Date: Tue, 27 Jan 2009 14:09:12 +0100	[thread overview]
Message-ID: <20090127130912.GA25722@buzzloop.caiaq.de> (raw)
In-Reply-To: <20081214113910.GA8678@buzzloop.caiaq.de>

Picking up an acient thread,

On Sun, Dec 14, 2008 at 12:39:10PM +0100, Daniel Mack wrote:
> On Sun, Dec 14, 2008 at 12:12:24PM +0100, Wolfgang Denk wrote:
> > > This adds CONFIG_NE2000_NOPROM. If set, the ethernet MAC address is taken
> > > from the environment variable 'ethaddr' and the NIC is configured
> > > accordingly. Needed for boards that don't have an EEPROM to store this
> > > setting permanently.
> > > 
> > > Signed-off-by: Daniel Mack <daniel@caiaq.de>
> > > 
> > > ---
> > >  ne2000_base.c |   38 ++++++++++++++++++++++++++++----------
> > >   1 file changed, 28 insertions(+), 10 deletions(-)
> > 
> > Why do we need a special CONFIG_ option? is it not possible to detect
> > (by software) that there is no EEPROM available, and auto-adjust?
> 
> Hmm, what's bad about a special config variable? I agree that in
> general, auto-probing is a good thing, but in U-Boot with its per-board
> configuration file concept, I don't see much advantage. It is very
> unlikely that a certain board is produced with and without an EEPROM.
> 
> > Note that there is existing policy how to handle the  situation  that
> > we have both a MAC address stored in some other storeage (like EEPROM
> > on  the  NIC)  and  in  the  "ethaddr"  environment variable (see for
> > example drivers/net/cs8900.c). In the end, the code shall always only
> > rely on the U-Boot environment settings.
> 
> I can send a new version of this patch following this, but I wonder
> why such a logic has to be implemented in the ethernet drivers and did
> not find a well-defined place in some kind of layer all drivers make use
> of? Wouldn't it make more sense to put some effort in this direction?

Is there any reason why there was no reply to this anymore suddenly? Did
it sound like too much work for anyone to do it the right way? I'll get
back to this project soon and will need to address the same problems
agains like many weeks ago, and unfortunately, nothing happened to all
the issues I pointed out back then, not a single patch I sent in has been
taken.

Daniel

  reply	other threads:[~2009-01-27 13:09 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-28 16:16 [U-Boot] [PATCH] ne2000: take MAC address from config if available Daniel Mack
2008-11-29  5:27 ` Ben Warren
2008-11-29 13:17   ` Daniel Mack
2008-12-03  1:01     ` Daniel Mack
2008-12-14 11:12       ` Wolfgang Denk
2008-12-14 11:39         ` Daniel Mack
2009-01-27 13:09           ` Daniel Mack [this message]
2009-01-27 13:31             ` Wolfgang Denk

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=20090127130912.GA25722@buzzloop.caiaq.de \
    --to=daniel@caiaq.de \
    --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