[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1236780016.10989.9.camel@localhost.localdomain>
Date: Wed, 11 Mar 2009 10:00:16 -0400
From: Dan Williams <dcbw@...hat.com>
To: David Miller <davem@...emloft.net>
Cc: wd@...x.de, shemminger@...tta.com, yanok@...raft.com,
linux-arm-kernel@...ts.arm.linux.org.uk, netdev@...r.kernel.org,
dzu@...x.de
Subject: Re: [PATCH] dnet: Dave DNET ethernet controller driver
On Wed, 2009-03-11 at 06:23 -0700, David Miller wrote:
> From: Wolfgang Denk <wd@...x.de>
> Date: Wed, 11 Mar 2009 10:09:38 +0100
>
> > How do you then handle situations where this is impossible? Say, when
> > the firmware cannot write to those registers for example because the
> > ethernet controller is not even powered on (to reduce power consump-
> > tion), but will get powered on only in Linux when the driver gets
> > loaded (i. e. on demand only, not always)?
>
> That's what NVRAM, CMOS, EEPROM's and other writable long-term
> storage areas are for.
>
> To be quite honest with you, any ethernet device that doesn't
> have an EEPROM where the chip instance's ethernet address is
> stored is completely broken.
Not having persistent MAC storage makes it quite hard from userspace to
tie specific network configuration to a specific device, because
(rightly so) kernel network interface names are *not* stable. And since
most manufacturers don't bother to put serial numbers into things like
the USB descriptors, there is now way to uniquely identify if you plug
two in. LOSE.
Save a kitten. Add an EEPROM.
Dan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists