netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Gehrlein <sew_s@tqs.de>
To: Steve.Glendinning@smsc.com
Cc: netdev@vger.kernel.org
Subject: Re: [Uclinux-dist-devel] [PATCH 01/01] smsc911x: fix MAC addresssetting after reset
Date: Thu, 05 Jun 2008 12:23:35 +0200	[thread overview]
Message-ID: <4847BEA7.4050403@tqs.de> (raw)
In-Reply-To: <OF45087A0F.05ABBB48-ON8025745F.00349549-8025745F.0035BEBE@smsc.com>

Hi Steve,

Steve.Glendinning@smsc.com schrieb:
> Hi Jens,
> 
>> Sorry. Newbie question:
>> How can I pass the MAC address via kernel command line for this driver? 
>> Is there a predefined parameter?
>> My problem is:
>> U-Boot resets the chip after each completed transfer. Wolfgang Denk 
>> suggested to pass the MAC address via kernel command line. I need the 
>> ethernet device at kernel startup to mount a root filesystem via NFS, so 
> 
>> I added the platform device in my board specific code as shown below (it 
> 
>> still relates to the old driver).
>> Should I patch the driver directly to get the MAC address via __setup()
>> or can I pass the MAC address via the device structures.
>>
>> What do you suggest?
> 
> The smsc911x driver accepts mac addresses set "by configuration", so if 
> brought up after boot you could assign the mac address like this:
> 
> ifconfig eth0 hw ether 00:11:22:33:44:55 up
> 
> But as you're using an NFS root, you need to assign the mac address during 
> boot.  I'm not sure of the best way to do this, there isn't currently a 
> dev_addr field in smsc911x_platform_config, but you could add one.
> 
> Alternatively, if the bootloader already sets the mac address you could 
> modify the driver to read it off the device (into dev->dev_addr) before 
> resetting it?

My hope was, that U-Boot leaves the MAC address in the controller's 
register, but it resets the chip. We don't have an EEPROM connected to 
the controller. Unfortunately, ARM Linux doesn't provide board info 
structures or flat device tree like PowerPC Linux to pass data from the 
bootloader to the Kernel.

Additionally, I didn't succeed in compiling your new driver with Kernel 
2.6.22, because the Kernel API changed, and I can't switch to a new 
kernel. So I'm creating a private patch: getting the the MAC address 
from private kernel commmand line parameter using __setup().

However, as a suggestion for improvement of your new driver: could you 
extend the code, so that the board specific code could pass the MAC 
address via "struct platform_device", e.g. using the struct member .dev? 
Like using ifconfig it would allow multiple instances and the board 
specific code can take care, where it get the MAC addresses from.

Best regards,
Jens

      reply	other threads:[~2008-06-05 10:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-19 13:03 [Uclinux-dist-devel] [PATCH 01/01] smsc911x: fix MAC addresssetting after reset Steve.Glendinning
2008-06-02 18:38 ` Peter Korsgaard
2008-06-03 10:01 ` Jens Gehrlein
2008-06-05  9:47   ` Steve.Glendinning
2008-06-05 10:23     ` Jens Gehrlein [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=4847BEA7.4050403@tqs.de \
    --to=sew_s@tqs.de \
    --cc=Steve.Glendinning@smsc.com \
    --cc=netdev@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).